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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick > Sent: 14 January 2002 12:03 > To: [EMAIL PROTECTED] > Subject: Re: HEAD dumps core with APR_POOL_DEBUG > > > "Sander Striker" <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | PGP public key at web site: > http://www.geocities.com/SiliconValley/Park/9289/ > Born in Roswell... married an alien... > >
