> Am 20.02.2017 um 10:36 schrieb Stefan Priebe <[email protected]>: > > Hi, > > still not a single segfault with mod_http2 1.9.0 - good work!
Thanks! Our pleasure. Enjoy it until I break something in the next releases. > @Yann > Could you please tell me whether i should drop of your additional patches? > > Greets, > Stefan > > Am 09.02.2017 um 11:55 schrieb Stefan Priebe - Profihost AG: >> 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 >>>> <[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 >>> Stefan Eissing <green/>bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
