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.pri...@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....@gmail.com>: >>>>>> >>>>>> On Mon, Feb 6, 2017 at 2:31 PM, Stefan Eissing >>>>>> <stefan.eiss...@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 >
