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

Attachment: h2_session_clean.diff
Description: Binary data

 

> 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

Reply via email to