Am 19.01.2017 um 15:05 schrieb Stefan Eissing: > I prefer on top of v1.8.8, but it's your installation. Should also work on > older versions.
got this one: (gdb) bt #0 0x00007f4c424ec014 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f4c4297f036 in ?? () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0 #2 0x00007f4c4297f46f in apr_hash_set () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0 #3 0x000000000052a26d in h2_ihash_remove () #4 0x0000005b00000000 in ?? () #5 0x00007f4c2217b328 in ?? () #6 0x00007f4c22fec300 in ?? () #7 0x0000000000506b24 in purge_stream () #8 0x00007f4c206f50a0 in ?? () #9 0x00007f4c209eb118 in ?? () #10 0x00007f4c216f70a0 in ?? () #11 0x0000005b00000000 in ?? () #12 0x00007f4c206f50a0 in ?? () #13 0x00007f4c209eb118 in ?? () #14 0x00007f4c22fec340 in ?? () #15 0x000000000052a1c4 in ihash_iter () #16 0x00007f4c206f50a0 in ?? () #17 0x0000000000000004 in ?? () #18 0x00007f4c206f50a0 in ?? () #19 0x00007f4c22fec3c0 in ?? () #20 0x0000000000000000 in ?? () i've now removed any mpm_event patch and try to look again at v1.8.8 + your patch. Stefan > >> Am 19.01.2017 um 15:00 schrieb Stefan Priebe - Profihost AG >> <s.pri...@profihost.ag>: >> >> Hi, >> >> on top of v1.8.8? >> >> @Yann: >> should i use V7 or V6? >> >> Stefan >> >> Am 19.01.2017 um 14:56 schrieb Stefan Eissing: >>> Stefan, >>> >>> could you check if the attached patch mitigates the problem at least to >>> some extend? Was suggested to me by Yann, all faults are mine. Thanks! >>> >>> Cheers, Stefan >>> >>> >>> >>> >>> >>>> Am 19.01.2017 um 12:45 schrieb Stefan Priebe - Profihost AG >>>> <s.pri...@profihost.ag>: >>>> >>>> Am 19.01.2017 um 11:56 schrieb Stefan Eissing: >>>>> Stefan, >>>>> >>>>> yes, that is a known one that was addressed in v1.8.7. But I think it is >>>>> related to the others. There is some mistake in my thinking about session >>>>> pool cleanup that is more often uncovered by Yann's recent patches. I'll >>>>> need some deep dive into this one. >>>>> >>>>> For you, that means v1.8.8 is the best right now. Hopefully we'll find >>>>> this soon. >>>> >>>> But v1.8.8 is def. more often crashing than v1.8.3 which is included in >>>> apache 2.4.25. >>>> >>>> With v.8.8 i see crashes like these which i don't have with 1.8.3: >>>> (gdb) bt >>>> #0 0x00007f6b5f9fef23 in apr_brigade_length () from >>>> /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 >>>> #1 0x000000000052afb6 in h2_util_bb_avail () >>>> #2 0x00000000407e7a10 in ?? () >>>> #3 0x00007f6b407e7a8c in ?? () >>>> #4 0x00007f6b407e7a90 in ?? () >>>> #5 0x00007f6b3e608668 in ?? () >>>> #6 0x0000000000000000 in ?? () >>>> >>>> Greets, >>>> Stefan >>>> >>>>> >>>>> Cheers, >>>>> >>>>> Stefan >>>>> >>>>>> Am 19.01.2017 um 11:39 schrieb Stefan Priebe - Profihost AG >>>>>> <s.pri...@profihost.ag>: >>>>>> >>>>>> Hi, >>>>>> >>>>>> with V7 and mod_http2 core i'm always seeing exactly THIS trace and >>>>>> instead of every few minutes just once an hour: >>>>>> >>>>>> [Thread debugging using libthread_db enabled] >>>>>> 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 0x0000000000521d98 in h2_stream_out_prepare () >>>>>> (gdb) bt >>>>>> #0 0x0000000000521d98 in h2_stream_out_prepare () >>>>>> #1 0x00007fb65bfeea80 in ?? () >>>>>> #2 0x00007fb65bfeea8c in ?? () >>>>>> #3 0x00007fb65bfeea90 in ?? () >>>>>> #4 0x00007fb6599100a0 in ?? () >>>>>> #5 0x00007fb659910f70 in ?? () >>>>>> #6 0x00007fb65bfeeac0 in ?? () >>>>>> #7 0x0000000000000000 in ?? () >>>>>> >>>>>> not all the others like with v1.8.8. So may this be a different one? >>>>>> >>>>>> Stefan >>>>>> >>>>>> Am 19.01.2017 um 09:21 schrieb Stefan Priebe - Profihost AG: >>>>>>> And another one: >>>>>>> >>>>>>> #0 0x00007f7d81ba1f23 in apr_brigade_length () from >>>>>>> /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 >>>>>>> (gdb) bt >>>>>>> #0 0x00007f7d81ba1f23 in apr_brigade_length () from >>>>>>> /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 >>>>>>> #1 0x000000000052a8bc in h2_util_bb_avail () >>>>>>> #2 0x000000007112ca10 in ?? () >>>>>>> #3 0x00007f7d7112ca8c in ?? () >>>>>>> #4 0x00007f7d7112ca90 in ?? () >>>>>>> #5 0x00007f7d60a4bad0 in ?? () >>>>>>> #6 0x0000000000000000 in ?? () >>>>>>> Am 19.01.2017 um 09:20 schrieb Stefan Priebe - Profihost AG: >>>>>>>> Hi, >>>>>>>> Am 19.01.2017 um 09:11 schrieb Yann Ylavic: >>>>>>>>> On Thu, Jan 19, 2017 at 9:05 AM, Stefan Priebe - Profihost AG >>>>>>>>> <s.pri...@profihost.ag> wrote: >>>>>>>>>> With a vanilla apache 2.4.25 i got this one: >>>>>>>>>> >>>>>>>>>> Core was generated by `/usr/local/apache2/bin/httpd -k start'. >>>>>>>>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>>>>>>>> #0 0x00007fe2bb7b8add in read () from >>>>>>>>>> /lib/x86_64-linux-gnu/libpthread.so.0 >>>>>>>>>> (gdb) bt >>>>>>>>>> #0 0x00007fe2bb7b8add in read () from >>>>>>>>>> /lib/x86_64-linux-gnu/libpthread.so.0 >>>>>>>>>> #1 0x000000000048043a in ap_mpm_podx_check () >>>>>>>>>> #2 <signal handler called> >>>>>>>>>> #3 0x000000004b351bd0 in ?? () >>>>>>>>>> Cannot access memory at address 0x0 >>>>>>>>> >>>>>>>>> This is probably not the faulting thread, could you find it with >>>>>>>>> "thread apply all bt" or paste the whole output please? >>>>>>>> >>>>>>>> ah i found it via thread apply all bt: >>>>>>>> >>>>>>>> (gdb) bt >>>>>>>> #0 0x0000000000521d98 in h2_stream_out_prepare () >>>>>>>> #1 0x00007f5cbdfeaa80 in ?? () >>>>>>>> #2 0x00007f5cbdfeaa8c in ?? () >>>>>>>> #3 0x00007f5cbdfeaa90 in ?? () >>>>>>>> #4 0x00007f5cb97ec0a0 in ?? () >>>>>>>> #5 0x00007f5cb97ec988 in ?? () >>>>>>>> #6 0x00007f5cbdfeaac0 in ?? () >>>>>>>> #7 0x0000000000000000 in ?? () >>>>>>>> >>>>>>>> this is with a vanilla 2.4.25. >>>>>>>> >>>>>>>> Greets, >>>>>>>> Stefan >>>>>>>> >>>>> >>>>> 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 >
