Hi Stefan,
thanks. No crashes where h2 comes up. But i still have these and no idea
how to find out who and why they're crashing.
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache2/bin/httpd -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 allocator_free (node=0x0, allocator=0x7f6e08066540)
at memory/unix/apr_pools.c:381
#0 allocator_free (node=0x0, allocator=0x7f6e08066540)
at memory/unix/apr_pools.c:381
#1 apr_pool_clear (pool=0x7f6e0808d238) at memory/unix/apr_pools.c:793
#2 0x00000000004fe528 in ap_push_pool (queue_info=0x0,
pool_to_recycle=0x7f6e08066548) at fdqueue.c:234
#3 0x00000000004fa2c8 in process_lingering_close (cs=0x7f6e0808d4c8,
pfd=0x1d3bf98) at event.c:1439
#4 0x00000000004fd410 in listener_thread (thd=0x1d3cb70,
dummy=0x7f6e0808d4c8)
at event.c:1704
#5 0x00007f6e1aed20a4 in start_thread ()
from /lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f6e1aa0362d in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) (gdb) quit
Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from
/usr/lib/debug//usr/local/apache2/bin/httpd...done.
done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache2/bin/httpd -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 allocator_free (node=0x0, allocator=0x7f6e08053ae0)
at memory/unix/apr_pools.c:381
#0 allocator_free (node=0x0, allocator=0x7f6e08053ae0)
at memory/unix/apr_pools.c:381
#1 apr_pool_clear (pool=0x7f6e08076bb8) at memory/unix/apr_pools.c:793
#2 0x00000000004fe528 in ap_push_pool (queue_info=0x0,
pool_to_recycle=0x7f6e08053ae8) at fdqueue.c:234
#3 0x00000000004fa2c8 in process_lingering_close (cs=0x7f6e08076e48,
pfd=0x1d3bf98) at event.c:1439
#4 0x00000000004fd410 in listener_thread (thd=0x1d3cb70,
dummy=0x7f6e08076e48)
at event.c:1704
#5 0x00007f6e1aed20a4 in start_thread ()
from /lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f6e1aa0362d in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) (gdb) quit
Stefan
Am 21.01.2017 um 17:03 schrieb Stefan Eissing:
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
