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. 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
