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 >