On Thu, Sep 1, 2011 at 13:52, Joshua Marantz <jmara...@google.com> wrote: > Hi, > > I've been load-testing our module > (mod_pagespeed<http://code.google.com/speed/page-speed/docs/module.html>) > with httpd 2.2.16 built with these options: > --enable-pool-debug --with-mpm=worker > I've been getting periodic aborts from apr_table_addn that don't look like > they are from my module. These do not occur when using 'prefork'. > > Here's a stack-trace recovered from a core file: > > Program terminated with signal 6, Aborted. > #0 0x00007fdd3bbd9a75 in raise (sig=<value optimized out>) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. > in ../nptl/sysdeps/unix/sysv/linux/raise.c > (gdb) where > #0 0x00007fdd3bbd9a75 in raise (sig=<value optimized out>) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #1 0x00007fdd3bbdd5c0 in abort () at abort.c:92 > #2 0x00007fdd3c9a2e57 in apr_table_addn (t=0xe84980, key=0xd51d60 > "Accept-Encoding", val=0xd51d71 "identity") at tables/apr_tables.c:813 > #3 0x0000000000433e36 in ap_get_mime_headers_core (r=0xf27de0, bb=0xdda3a0) > at protocol.c:799 > #4 0x000000000043456b in ap_read_request (conn=0xe51620) at protocol.c:918 > #5 0x000000000047f772 in ap_process_http_connection (c=0xe51620) at > http_core.c:183 > #6 0x0000000000446e28 in ap_run_process_connection (c=0xe51620) at > connection.c:43 > #7 0x00000000004b3297 in process_socket (thd=<value optimized out>, > dummy=<value optimized out>) at worker.c:544 > #8 worker_thread (thd=<value optimized out>, dummy=<value optimized out>) > at worker.c:894 > #9 0x00007fdd3c1339ca in start_thread (arg=<value optimized out>) at > pthread_create.c:300 > #10 0x00007fdd3bc8c70d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 > > > Questions > > 1. Is this a bug in httpd?
Probably not. > 2. Or could I somehow have caused this with a programming error in my > module? That seems more likely. > 3. Or is enable-pool-debug simply incompatible with the Worker MPM? Not that I know. That assertion is triggered when you add a string from pool A to a table in pool B where A is a child of B (adding headers from the request_rec to a conn_rec table, for example). It's a lifecycle issue.
