httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Priebe - Profihost AG <s.pri...@profihost.ag>
Subject Re: mod_http2 and Frequent wake-ups for mpm_event
Date Thu, 19 Jan 2017 15:02:29 GMT

Am 19.01.2017 um 15:05 schrieb Stefan Eissing:
> I prefer on top of v1.8.8, but it's your installation. Should also work on older versions.

got this one:
(gdb) bt
#0  0x00007f4c424ec014 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f4c4297f036 in ?? () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0
#2  0x00007f4c4297f46f in apr_hash_set () from
/usr/lib/x86_64-linux-gnu/libapr-1.so.0
#3  0x000000000052a26d in h2_ihash_remove ()
#4  0x0000005b00000000 in ?? ()
#5  0x00007f4c2217b328 in ?? ()
#6  0x00007f4c22fec300 in ?? ()
#7  0x0000000000506b24 in purge_stream ()
#8  0x00007f4c206f50a0 in ?? ()
#9  0x00007f4c209eb118 in ?? ()
#10 0x00007f4c216f70a0 in ?? ()
#11 0x0000005b00000000 in ?? ()
#12 0x00007f4c206f50a0 in ?? ()
#13 0x00007f4c209eb118 in ?? ()
#14 0x00007f4c22fec340 in ?? ()
#15 0x000000000052a1c4 in ihash_iter ()
#16 0x00007f4c206f50a0 in ?? ()
#17 0x0000000000000004 in ?? ()
#18 0x00007f4c206f50a0 in ?? ()
#19 0x00007f4c22fec3c0 in ?? ()
#20 0x0000000000000000 in ?? ()

i've now removed any mpm_event patch and try to look again at v1.8.8 +
your patch.

Stefan

> 
>> Am 19.01.2017 um 15:00 schrieb Stefan Priebe - Profihost AG <s.priebe@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.priebe@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.priebe@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.priebe@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
> 

Mime
View raw message