Stefan, this seems to be a tough bone to chew. Therefore we need to go deeper: - can you compile the module so that we see line numbers in the trace? - which apr version are you using? - can you reproduce this at will? How? Which client? Just a GET or something more sophisticated?
Thanks for the help! Cheers, Stefan > Am 19.01.2017 um 22:01 schrieb Stefan Priebe - Profihost AG > <[email protected]>: > > new segfault with both patches on top of v1.8.8: > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > Core was generated by `/usr/local/apache2/bin/httpd -k start'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00007fbefce0d014 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #0 0x00007fbefce0d014 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x00007fbefd2a0036 in ?? () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0 > #2 0x00007fbefd2a046f in apr_hash_set () from > /usr/lib/x86_64-linux-gnu/libapr-1.so.0 > #3 0x000000000052a26b in h2_ihash_remove () > #4 0x0000000000506b24 in purge_stream () > #5 0x000000000052a1c2 in ihash_iter () > #6 0x00007fbefd2a08a6 in apr_hash_do () from > /usr/lib/x86_64-linux-gnu/libapr-1.so.0 > #7 0x000000000052a200 in h2_ihash_iter () > #8 0x0000000000506b65 in purge_streams () > #9 0x00000000005082dd in h2_mplx_release_and_join () > #10 0x00000000005158f9 in h2_session_cleanup () > #11 0x00000000005164a4 in session_pool_cleanup () > #12 0x00007fbefd2a9976 in apr_pool_destroy () from > /usr/lib/x86_64-linux-gnu/libapr-1.so.0 > #13 0x00007fbefd2a9c55 in apr_pool_clear () from > /usr/lib/x86_64-linux-gnu/libapr-1.so.0 > #14 0x0000000000566acd in ap_push_pool () > #15 0x000000000056008a in process_lingering_close () > #16 0x0000000000560ced in listener_thread () > #17 0x00007fbefd0780a4 in start_thread () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #18 0x00007fbefcdad62d in clone () from /lib/x86_64-linux-gnu/libc.so.6 > > Stefan > > Am 19.01.2017 um 21:48 schrieb Stefan Eissing: >> On top please. There is only one way: forward! >> >>> Am 19.01.2017 um 21:47 schrieb Stefan Priebe - Profihost AG >>> <[email protected]>: >>> >>> >>> Am 19.01.2017 um 21:39 schrieb Stefan Eissing: >>>> Thanks, Stefan. Can you given the attached Patch a try? >>> >>> sure. On top of the last one? Or should i drop it? >>> >>> >>> Stefan >>> >>>>> Am 19.01.2017 um 19:33 schrieb Stefan Priebe <[email protected]>: >>>>> >>>>> Here some more segfaults from 2.4.25 no mpm patch but http2 v1.8.8: >>>>> >>>>> ################################################################# >>>>> >>>>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >>>>> Core was generated by `/usr/local/apache2/bin/httpd -k start'. >>>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>>> #0 0x00007f61f673b014 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 >>>>> #0 0x00007f61f673b014 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 >>>>> #1 0x00007f61f6bce036 in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0 >>>>> #2 0x00007f61f6bce46f in apr_hash_set () from >>>>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0 >>>>> #3 0x000000000052a26d in h2_ihash_remove () >>>>> #4 0x0000000000506b24 in purge_stream () >>>>> #5 0x000000000052a1c4 in ihash_iter () >>>>> #6 0x00007f61f6bce8a6 in apr_hash_do () from >>>>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0 >>>>> #7 0x000000000052a202 in h2_ihash_iter () >>>>> #8 0x0000000000506b65 in purge_streams () >>>>> #9 0x00000000005082df in h2_mplx_release_and_join () >>>>> #10 0x00000000005158fb in h2_session_cleanup () >>>>> #11 0x00000000005164a6 in session_pool_cleanup () >>>>> #12 0x00007f61f6bd7976 in apr_pool_destroy () from >>>>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0 >>>>> #13 0x00007f61f6bd7c55 in apr_pool_clear () from >>>>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0 >>>>> #14 0x0000000000566acf in ap_push_pool () >>>>> #15 0x000000000056008c in process_lingering_close () >>>>> #16 0x0000000000560cef in listener_thread () >>>>> #17 0x00007f61f69a60a4 in start_thread () from >>>>> /lib/x86_64-linux-gnu/libpthread.so.0 >>>>> #18 0x00007f61f66db62d in clone () from /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> ################################################################# >>>>> >>>>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >>>>> Core was generated by `/usr/local/apache2/bin/httpd -k start'. >>>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>>> #0 0x00007f61f673b014 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 >>>>> #0 0x00007f61f673b014 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 >>>>> #1 0x00007f61f6bce036 in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0 >>>>> #2 0x00007f61f6bce46f in apr_hash_set () from >>>>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0 >>>>> #3 0x000000000052a26d in h2_ihash_remove () >>>>> #4 0x0000000000506b24 in purge_stream () >>>>> #5 0x000000000052a1c4 in ihash_iter () >>>>> #6 0x00007f61f6bce8a6 in apr_hash_do () from >>>>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0 >>>>> #7 0x000000000052a202 in h2_ihash_iter () >>>>> #8 0x0000000000506b65 in purge_streams () >>>>> #9 0x00000000005082df in h2_mplx_release_and_join () >>>>> #10 0x00000000005158fb in h2_session_cleanup () >>>>> #11 0x00000000005164a6 in session_pool_cleanup () >>>>> #12 0x00007f61f6bd7976 in apr_pool_destroy () from >>>>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0 >>>>> #13 0x00007f61f6bd7c55 in apr_pool_clear () from >>>>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0 >>>>> #14 0x0000000000566acf in ap_push_pool () >>>>> #15 0x000000000056008c in process_lingering_close () >>>>> #16 0x0000000000560cef in listener_thread () >>>>> #17 0x00007f61f69a60a4 in start_thread () from >>>>> /lib/x86_64-linux-gnu/libpthread.so.0 >>>>> #18 0x00007f61f66db62d in clone () from /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> ################################################################# >>>>> >>>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>>> #0 0x00007f204f922d63 in apr_pool_cleanup_kill () from >>>>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0 >>>>> (gdb) bt >>>>> #0 0x00007f204f922d63 in apr_pool_cleanup_kill () from >>>>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0 >>>>> #1 0x00007f204f922e21 in apr_pool_cleanup_run () from >>>>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0 >>>>> #2 0x000000000055ffe9 in process_lingering_close () >>>>> #3 0x0000000000560cef in listener_thread () >>>>> #4 0x00007f204f6f00a4 in start_thread () from >>>>> /lib/x86_64-linux-gnu/libpthread.so.0 >>>>> #5 0x00007f204f42562d in clone () from /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> full bt: >>>>> http://pastebin.com/raw/bP1vaYjw >>>>> >>>>> ################################################################# >>>>> >>>>> Greets, >>>>> Stefan >>>>> >>>>> Am 19.01.2017 um 16:47 schrieb Stefan Priebe - Profihost AG: >>>>>> arg sorry my fault. >>>>>> >>>>>> Here is a complete trace: >>>>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>>>> #0 0x00007fc1c23e0f23 in apr_brigade_length () from >>>>>> /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 >>>>>> (gdb) bt >>>>>> #0 0x00007fc1c23e0f23 in apr_brigade_length () from >>>>>> /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 >>>>>> #1 0x000000000052a8f1 in h2_util_bb_avail () >>>>>> #2 0x0000000000521eaa in h2_stream_out_prepare () >>>>>> #3 0x000000000051a55a in on_stream_resume () >>>>>> #4 0x000000000050bdff in h2_mplx_dispatch_master_events () >>>>>> #5 0x000000000051dc32 in h2_session_process () >>>>>> #6 0x0000000000500115 in h2_conn_run () >>>>>> #7 0x0000000000504b51 in h2_h2_process_conn () >>>>>> #8 0x000000000047cb19 in ap_run_process_connection () >>>>>> #9 0x000000000055e755 in process_socket () >>>>>> #10 0x0000000000560f5c in worker_thread () >>>>>> #11 0x00007fc1c1f8d0a4 in start_thread () from >>>>>> /lib/x86_64-linux-gnu/libpthread.so.0 >>>>>> #12 0x00007fc1c1cc262d in clone () from /lib/x86_64-linux-gnu/libc.so.6 >>>>>> >>>>>> Stefan >>>>>> >>>>>> Am 19.01.2017 um 16:45 schrieb Stefan Priebe - Profihost AG: >>>>>>> >>>>>>> Am 19.01.2017 um 16:34 schrieb Stefan Eissing: >>>>>>>> Yann might already have asked this: any chance to compile with symbols >>>>>>>> and get a more readable stacktrace? >>>>>>> >>>>>>> Yes just tell me how ;-) i'm using dpkg-buildpackage and dh_strip. I've >>>>>>> no idea why not all symbols are available. >>>>>>> >>>>>>> Do i need to pass a specific option to configure >>>>>>> >>>>>>> Stefan >>>>>>> >>>>>>>>> Am 19.01.2017 um 16:30 schrieb Stefan Priebe - Profihost AG >>>>>>>>> <[email protected]>: >>>>>>>>> >>>>>>>>> With stock 2.4.25 + patch i'm getting this one again: >>>>>>>>> (gdb) bt >>>>>>>>> #0 0x0000000000521dcd in h2_stream_out_prepare () >>>>>>>>> #1 0x00007fc1a2feca80 in ?? () >>>>>>>>> #2 0x00007fc1a2feca8c in ?? () >>>>>>>>> #3 0x00007fc1a2feca90 in ?? () >>>>>>>>> #4 0x00007fc1a057c0a0 in ?? () >>>>>>>>> #5 0x00007fc1a057cdd8 in ?? () >>>>>>>>> #6 0x00007fc1a2fecac0 in ?? () >>>>>>>>> #7 0x0000000000000000 in ?? () >>>>>>>>> >>>>>>>>> Stefan >>>>>>>>> >>>>>>>>> Am 19.01.2017 um 16:28 schrieb Stefan Priebe - Profihost AG: >>>>>>>>>> I'm now testing stock 2.4.25 + patch. >>>>>>>>>> >>>>>>>>>> May this configure option have an influence? >>>>>>>>>> --enable-nonportable-atomics=yes >>>>>>>>>> >>>>>>>>>> Greets, >>>>>>>>>> Stefan >>>>>>>>>> >>>>>>>>>> Am 19.01.2017 um 15:35 schrieb Yann Ylavic: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On Thu, Jan 19, 2017 at 3:00 PM, Stefan Priebe - Profihost AG >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> @Yann: >>>>>>>>>>>> should i use V7 or V6? >>>>>>>>>>> >>>>>>>>>>> I'd prefer you'd use none (such that we can verify the patch with >>>>>>>>>>> stock 2.4.25, modulo mod_http2), but if it's easier for you to >>>>>>>>>>> reproduce with an event's patch, please use the v6 (and if it fails >>>>>>>>>>> then v7, and if it fails then no patch, really). >>>>>>>>>>> >>>>>>>> >>>>>>>> Stefan Eissing >>>>>>>> >>>>>>>> <green/>bytes GmbH >>>>>>>> Hafenstrasse 16 >>>>>>>> 48155 Münster >>>>>>>> www.greenbytes.de >>>>>>>> >>>> >>>> Stefan Eissing >>>> >>>> <green/>bytes GmbH >>>> Hafenstrasse 16 >>>> 48155 Münster >>>> www.greenbytes.de >>>> >> >> Stefan Eissing >> >> <green/>bytes GmbH >> Hafenstrasse 16 >> 48155 Münster >> www.greenbytes.de >> Stefan Eissing <green/>bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
