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, 09 Feb 2017 10:55:48 GMT
Hi Stefan,

Am 09.02.2017 um 11:47 schrieb Stefan Eissing:
> Stefan,
> 
> at this point and after several efforts to write the right patch, I reached the conclusion
that I need to rethink the pool hierarchy and connection shutdown strategy in mod_http2. The
current, organically grown implementation needs a refactor with the knowledge we have made
so far.

OK - thanks for your help and hard work.

> So, a fix will not come today or tomorrow. But not too far away either. From your comments
I assume that these crashed happen not too frequently. Hope this allows you to live with the
current state for a while.

Sure and yes it does not happen very often.

> Btw. have the status 500 lines disappeared with the latest release? That was one point
still open on my list...

Yes sorry i missed to report back. It's working fine now.

> 
> Hope to give you something better to verify in your environment soon.

Just tell me i'm ready to test.

Greets,
Stefan

> Cheers,
> 
> Stefan
> 
>> Am 07.02.2017 um 20:56 schrieb Stefan Priebe - Profihost AG <s.priebe@profihost.ag>:
>>
>> Hi,
>>
>> got this one today with both patches applied:
>>
>> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  allocator_free (node=0x0, allocator=0x7f350405e030)
>>    at memory/unix/apr_pools.c:381
>> #0  allocator_free (node=0x0, allocator=0x7f350405e030)
>>    at memory/unix/apr_pools.c:381
>> #1  apr_pool_clear (pool=0x7f3504060468) at memory/unix/apr_pools.c:793
>> #2  0x000055d11256d688 in ap_push_pool (queue_info=0x7f35040604f8,
>>    pool_to_recycle=0xffffffff) at fdqueue.c:234
>> #3  0x000055d11256899a in process_lingering_close (cs=0x7f3504060748,
>>    pfd=0x55d1143fd7f8) at event.c:1513
>> #4  0x000055d11256c4d0 in listener_thread (thd=0x7f35040604f8,
>>    dummy=0x547f569acd4a6) at event.c:1837
>> #5  0x00007f351757c0a4 in start_thread ()
>>   from /lib/x86_64-linux-gnu/libpthread.so.0
>> #6  0x00007f35172b162d in clone () from /lib/x86_64-linux-gnu/libc.so.6
>>
>> Am 06.02.2017 um 22:24 schrieb Stefan Priebe - Profihost AG:
>>> Am 06.02.2017 um 22:22 schrieb Stefan Priebe - Profihost AG:
>>>> Hi Stefan,
>>>>
>>>> this one does not apply on top of yann's
>>>> mpm_event_listener_wakeup_bug57399_V7.patch patch.
>>>
>>> i've now used his patch to mpm and yours for mod_http2.
>>>
>>> Stefan
>>>
>>>>
>>>> Stefan
>>>> Am 06.02.2017 um 15:34 schrieb Stefan Eissing:
>>>>> Yes, that was mixing the order. The attached v4 compiles and runs the
h2 tests for me without errors.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Am 06.02.2017 um 14:43 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
>>>>>>
>>>>>> On Mon, Feb 6, 2017 at 2:31 PM, Stefan Eissing
>>>>>> <stefan.eissing@greenbytes.de> wrote:
>>>>>>> Currently running some tests. Have crashes on the original patch
in my test suite. Fixed one, hunting for the next...
>>>>>>
>>>>>> I think it comes from my change that creates slave connections from
>>>>>> master->pool (instead of mplx's), because now slave's pool is
already
>>>>>> destroyed when h2_mplx_release_and_join()->task_destroy()->h2_slave_destroy()
>>>>>> is called (hence the crash).
>>>>>>
>>>>>> I restored your original code in this new (attached) patch.
>>>>>>
>>>>>> @s.priebe, would you test this one please?
>>>>>> <ptrans_and_slaves_allocator-v3.patch>
>>>>>
>>>>> 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