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

Reply via email to