Inexplicable crash in apr_thread_exit

[Brent Gulanowski <br...@magma.ca>]

I'm trying to understand a crash, but I can't seem to get enough 
information from the debugger to understand it's cause. In one 
function, a variable looks ok, but in a function called from there with 
that variable as an argument, the variable has no value (0x00).

(gdb) bt
#0  apr_pool_destroy (pool=0x2885e18) at apr_pools.c:783
#1  0x0163a5ec in apr_thread_exit (thd=0x0, retval=42275328) at 
thread.c:192
#2  0x01521f3c in connect_thread_main (thread=0x287dea0, arg=0x55ece0) 
at jxta_rdv_service_client.c:2208
#3  0x900246e8 in _pthread_body ()

#2  0x01521f3c in connect_thread_main (thread=0x287dea0, arg=0x55ece0) 
at jxta_rdv_service_client.c:2208
2208	            apr_thread_exit(thread, JXTA_SUCCESS);
(gdb) print thread
$1 = (struct apr_thread_t *) 0x287dea0
(gdb) down
#1  0x0163a5ec in apr_thread_exit (thd=0x0, retval=42275328) at 
thread.c:192
192	    apr_pool_destroy(thd->pool);
(gdb) print thd
$2 = (apr_thread_t *) 0x0


The variables "thread" and "thd" should have the same value;

Code:
APR_DECLARE(apr_status_t) apr_thread_exit(apr_thread_t *thd,
                                           apr_status_t retval)
{
     thd->exitval = retval;
     apr_pool_destroy(thd->pool);
     pthread_exit(NULL);
     return APR_SUCCESS;
}

but it doesn't crash until apr_pool_destroy (which I really don't 
understand, if thd is 0x0) when parts of "pool" are accessed illegally.

BTW, this is one of those times that it would really make sense to use 
the same name for the same kind of variable; in this case, changing 
"thd" to "thread". How much typing did "thd" really save?

Thanks,


--
Brent Gulanowski				brentg@magma.ca

Re: Inexplicable crash in apr_thread_exit

[Joe Orton <jo...@redhat.com>]

On Wed, Jul 14, 2004 at 08:42:33AM -0400, Brent Gulanowski wrote:
> I'm trying to understand a crash, but I can't seem to get enough 
> information from the debugger to understand it's cause. In one 
> function, a variable looks ok, but in a function called from there with 
> that variable as an argument, the variable has no value (0x00).

Could be any random memory corruption issue or pool lifetime problems as
far as I can tell.  Building with --enable-pool-debug and then running
your program under electric fence is a good way to track these down.

(or enabling libc malloc checking e.g. export MALLOC_CHECK_=2 with 
glibc)

joe