httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: HEAD dumps core with APR_POOL_DEBUG
Date Mon, 14 Jan 2002 11:03:14 GMT
"Sander Striker" <striker@apache.org> writes:

> Hi,
> 
> I've fixed the integrity check now.
> If you are still seeing aborts, then we have a serious lifetime
> problem*.  If this is the case, try running with APR_POOL_DEBUG_VERBOSE.
> When you hit an abort, it will print:
> INVALID <address>
> 
> You can then scan back through the output for the address to
> see where it was DESTROYed (and CREATEd).
> 
> Sander
> 
> *) Or a bug in the debug code...

Okay, cvs HEAD, fresh build starting with extraclean, just plain
APR_POOL_DEBUG:

#0  0xff34c70c in pool_is_child_of (pool=0x1b3fb0, parent=0x6174652c,
 mutex=0x0) at apr_pools.c:900
900         if (parent->mutex && parent->mutex != mutex)
(gdb) where
#0  0xff34c70c in pool_is_child_of (pool=0x1b3fb0, parent=0x6174652c,
 mutex=0x0) at apr_pools.c:900
#1  0xff34c794 in pool_is_child_of (pool=0x1b3fb0, parent=0x1d2ca0,
 mutex=0x0) at apr_pools.c:906
#2  0xff34c794 in pool_is_child_of (pool=0x1b3fb0, parent=0x14a528,
 mutex=0x117aa8) at apr_pools.c:906
#3  0xff34c794 in pool_is_child_of (pool=0x1b3fb0, parent=0x117a60,
 mutex=0x0) at apr_pools.c:906
#4  0xff34c8dc in check_integrity (pool=0x1b3fb0) at apr_pools.c:950
#5  0xff34c910 in apr_palloc (pool=0x1b3fb0, size=19) at
 apr_pools.c:977
#6  0xff32bb10 in apr_pstrndup (a=0x1b3fb0, s=0xfb1077f5
 "index.html.tw.Big5\n", n=18)
    at apr_strings.c:96
#7  0xb60b8 in ap_get_token (p=0x1b3fb0, accept_line=0xfb10778c,
 accept_white=0) at util.c:1380
#8  0x876e8 in read_type_map (map=0xfb109888, neg=0x1ece78,
 rr=0x167750) at mod_negotiation.c:931
#9  0x8bc1c in handle_map_file (r=0x167750) at mod_negotiation.c:2781
#10 0xa6250 in ap_run_handler (r=0x167750) at config.c:185
#11 0xa6ec8 in ap_invoke_handler (r=0x167750) at config.c:359
#12 0x533c0 in ap_process_request (r=0x167750) at http_request.c:292
#13 0x4b1c0 in ap_process_http_connection (c=0x1b46b0) at
 http_core.c:280
#14 0xbab14 in ap_run_process_connection (c=0x1b46b0) at
 connection.c:84
#15 0xbb0cc in ap_process_connection (c=0x1b46b0) at connection.c:230
#16 0xa0b70 in process_socket (p=0x177110, sock=0x177290,
 my_child_num=0, my_thread_num=182)
    at worker.c:562
#17 0xa14b8 in worker_thread (thd=0x15ef40, dummy=0x15e230) at
 worker.c:777
#18 0xff340c48 in dummy_worker (opaque=0x15ef40) at thread.c:122
(gdb) p *parent
Cannot access memory at address 0x6174652c
(gdb)

Changing it to APR_POOL_DEBUG_VERBOSE && make clean && make && make
install:

(oh, I had to apply this patch first in order to use the
normally-commented-out define of APR_POOL_DEBUG_VERBOSE)

Index: memory/unix/apr_pools.c
===================================================================
RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
retrieving revision 1.133
diff -u -r1.133 apr_pools.c
--- memory/unix/apr_pools.c	14 Jan 2002 09:31:57 -0000	1.133
+++ memory/unix/apr_pools.c	14 Jan 2002 10:52:27 -0000
@@ -849,7 +849,7 @@
 
     apr_pools_initialized = 1;
 
-#if APR_POOL_DEBUG_VERBOSE
+#ifdef APR_POOL_DEBUG_VERBOSE
     apr_file_open_stderr(&file_stderr, global_pool);
     if (file_stderr) {
         apr_file_printf(file_stderr,
@@ -876,7 +876,7 @@
     apr_pool_destroy(global_pool); /* This will also destroy the mutex */
     global_pool = NULL;
 
-#if APR_POOL_DEBUG_VERBOSE
+#ifdef APR_POOL_DEBUG_VERBOSE
     file_stderr = NULL;
 #endif
 }

Here is the coredump I get (almost immediately after starting
pounding):

#0  0xff34d994 in pool_num_bytes (pool=0x14a3c8) at apr_pools.c:1381
1381            for (index = 0; index < node->index; index++) {
(gdb) where
#0  0xff34d994 in pool_num_bytes (pool=0x14a3c8) at apr_pools.c:1381
#1  0xff34da44 in apr_pool_num_bytes (pool=0x14a3c8, recurse=1) at
apr_pools.c:1395
#2  0xff34da8c in apr_pool_num_bytes (pool=0x14a3c8, recurse=1) at
apr_pools.c:1401
#3  0xff34da8c in apr_pool_num_bytes (pool=0x190968, recurse=1) at
apr_pools.c:1401
#4  0xff34cf7c in apr_pool_destroy_debug (pool=0x160d08,
file_line=0xff34ed98 "thread.c:182")
    at apr_pools.c:1091
#5  0xff340f2c in apr_thread_exit (thd=0x163f28, retval=0) at
thread.c:182
#6  0xa15bc in worker_thread (thd=0x163f28, dummy=0x1bb120) at
worker.c:788
#7  0xff340cc0 in dummy_worker (opaque=0x163f28) at thread.c:122
(gdb) p *node
Cannot access memory at address 0x208
(gdb) p *pool
$1 = {parent = 0x0, child = 0x0, sibling = 0x2077a8, ref = 0x19096c,
cleanups = 0x1cb810,
  subprocesses = 0x0, abort_fn = 0, user_data = 0x0, tag = 0xf7240
"protocol.c:575", nodes = 0x0,
  file_line = 0xf7240 "protocol.c:575", stat_alloc = 0,
stat_total_alloc = 373, stat_clear = 1,
  mutex = 0x0}
(gdb)

The only POOL DEBUG messages I get in the error_log are CLEAR (just
two, at initialization), CREATE, and DESTROY.  I'd expect some other
flavor if the pool code noticed a problem, right?

Thanks,

Jeff
-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Mime
View raw message