Stefan, made a release at https://github.com/icing/mod_h2/releases/tag/v1.8.9 with all patches and improved (hopefully) on them a bit. If you dare to drop that into your installation, that'd be great.
Cheers, Stefan > Am 21.01.2017 um 15:25 schrieb Stefan Priebe <s.pri...@profihost.ag>: > > and i got another crash here: > > 2346 static void run_cleanups(cleanup_t **cref) > 2347 { > 2348 cleanup_t *c = *cref; > 2349 > 2350 while (c) { > 2351 *cref = c->next; > 2352 (*c->plain_cleanup_fn)((void *)c->data); <== here > 2353 c = *cref; > 2354 > > which looks similar to the other crash. > > #0 0x00007fe4bbd33e1b in run_cleanups (cref=<optimized out>) at > memory/unix/apr_pools.c:2352 > #1 apr_pool_clear (pool=0x7fe4a804dac8) at memory/unix/apr_pools.c:772 > #2 0x00000000004feb38 in ap_push_pool (queue_info=0x6d616e79642d3733, > pool_to_recycle=0x2) at fdqueue.c:234 > #3 0x00000000004fa8d8 in process_lingering_close (cs=0x7fe4a804dd58, > pfd=0x25d3f98) at event.c:1439 > > Details: > (gdb) print c > $1 = (cleanup_t *) 0x7fe4a804e9f0 > (gdb) print *c > $2 = {next = 0x7fe4a804e870, data = 0x6d616e79642d3733, plain_cleanup_fn = > 0x392d3734322e6369, > child_cleanup_fn = 0x617465722e722d35} > (gdb) print *c->data > Attempt to dereference a generic pointer. > (gdb) print *c->plain_cleanup_fn > Cannot access memory at address 0x392d3734322e6369 > (gdb) > > Stefan > > Am 21.01.2017 um 15:18 schrieb Stefan Priebe: >> Hi, >> >> #0 apr_pool_cleanup_kill (p=0x7fe4a8072358, >> data=data@entry=0x7fe4a80723e0, >> cleanup_fn=cleanup_fn@entry=0x7fe4bbd38a40 <socket_cleanup>) at >> memory/unix/apr_pools.c:2276 >> >> it crashes here in apr: >> 2276 if (c->data == data && c->plain_cleanup_fn == cleanup_fn) { >> >> some lines before c becomes this >> 2264 c = p->cleanups; >> >> p is: >> (gdb) print *p >> $1 = {parent = 0x256f138, child = 0x7fe46c0751c8, sibling = >> 0x7fe4a8096888, ref = 0x7fe4a8069fe8, cleanups = 0x7fe478159748, >> free_cleanups = 0x7fe478159788, allocator = 0x7fe4a803b490, >> subprocesses = 0x0, abort_fn = 0x43da00 <abort_on_oom>, >> user_data = 0x0, tag = 0x502285 "transaction", active = >> 0x7fe478158d70, self = 0x7fe4a8072330, >> self_first_avail = 0x7fe4a80723d0 "X#\a\250\344\177", pre_cleanups = >> 0x7fe4a8072ab8} >> >> wouldn't the error mean that p->cleanups is NULL? >> >> (gdb) print *p->cleanups >> $2 = {next = 0x7fe478159628, data = 0x7fe478159648, plain_cleanup_fn = >> 0x7fe4bbd2ffd0 <apr_unix_file_cleanup>, >> child_cleanup_fn = 0x7fe4bbd2ff70 <apr_unix_child_file_cleanup>} >> >> So p->cleanups->data is 0x7fe478159648 and data is 0x7fe4a80723e0? >> >> I don't get why it's segfaulting >> >> Stefan >> Am 21.01.2017 um 09:50 schrieb Yann Ylavic: >>> Hi Stefan, >>> >>> On Sat, Jan 21, 2017 at 9:45 AM, Stefan Priebe <s.pri...@profihost.ag> >>> wrote: >>>> >>>> after running the whole night. These are the only ones still happening. >>>> Should i revert the mpm patch to check whether it's the source? >>> >>> Yes please, we need to determine... >>> >>> Thanks, >>> Yann. >>> Stefan Eissing <green/>bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de