Hi,
still not a single segfault with mod_http2 1.9.0 - good work!
@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
