As Rüdiger wrote, this stacktrace does not make any sense (to me), unless the pool cleanup messes up the stack.
Hmmm. This points to a major misconception of mine how things are supposed to happen. Will continue to look at this, but no easy solution in sight. > Am 27.01.2017 um 20:30 schrieb Ruediger Pluem <[email protected]>: > > > > On 01/27/2017 08:10 PM, Stefan Priebe - Profihost AG wrote: >> Hi Yann, >> >> this is now a segfault with mod_http2 + beam v4 patch + mpm v7 patch: >> Program terminated with signal SIGSEGV, Segmentation fault. >> #0 allocator_free (node=0x0, allocator=0x7f8974080c90) >> at memory/unix/apr_pools.c:381 >> #0 allocator_free (node=0x0, allocator=0x7f8974080c90) >> at memory/unix/apr_pools.c:381 >> #1 apr_pool_clear (pool=0x7f89740830d8) at memory/unix/apr_pools.c:793 > > pool from above != pool_to_recycle from below is strange. There is no modification to that parameter in this function. Which would mean the cleanup function/child pool destruction somehow garbles the stack??? Which would explain the strangeness below: >> #2 0x00005611421447a8 in ap_push_pool (queue_info=0x0, > > queue_info NULL? That looks bad. And that should have crashed at fdqueue.c line 225 already if queue_info == NULLL. >> pool_to_recycle=0x7f8974080c98) at fdqueue.c:234 >> #3 0x000056114213faea in process_lingering_close (cs=0x7f8974083368, >> pfd=0x561142cc97f8) at event.c:1513 >> #4 0x0000561142143620 in listener_thread (thd=0x0, dummy=0x54716c3684bbc) >> at event.c:1837 >> #5 0x00007f8989bb20a4 in start_thread () >> from /lib/x86_64-linux-gnu/libpthread.so.0 >> #6 0x00007f89898e762d in clone () from /lib/x86_64-linux-gnu/libc.so.6 > > Regards > > Rüdiger > Stefan Eissing <green/>bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
