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.
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. Btw. have the status 500 lines disappeared with the latest release? That was one point still open on my list... Hope to give you something better to verify in your environment soon. Cheers, Stefan > Am 07.02.2017 um 20:56 schrieb Stefan Priebe - Profihost AG > <[email protected]>: > > 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 <[email protected]>: >>>>> >>>>> On Mon, Feb 6, 2017 at 2:31 PM, Stefan Eissing >>>>> <[email protected]> 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
