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
> 

Reply via email to