I prefer on top of v1.8.8, but it's your installation. Should also work on older versions.
> 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
