httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: HEAD dumps core with APR_POOL_DEBUG
Date Mon, 14 Jan 2002 11:11:14 GMT
Jeff, I'll look into this straight away.
Seems that the addition of simple stats are breaking things.
Will take a few minutes.  Expect a commit soon.

Sander

> -----Original Message-----
> From: trawick@rdu163-40-092.nc.rr.com
> [mailto:trawick@rdu163-40-092.nc.rr.com]On Behalf Of Jeff Trawick
> Sent: 14 January 2002 12:03
> To: dev@httpd.apache.org
> Subject: Re: HEAD dumps core with APR_POOL_DEBUG
> 
> 
> "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