apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: pool problems with HEAD??
Date Thu, 10 Jan 2002 18:16:23 GMT
[...]
> > (2) revert plog/pconf patch and see what happens
> 
> I applied this patch:
> 
> Index: server/core.c
> ===================================================================
> RCS file: /cvs/apache/httpd-2.0/server/core.c,v
> retrieving revision 1.128
> diff -u -r1.128 core.c
> --- core.c      2002/01/08 17:07:19     1.128
> +++ core.c      2002/01/10 17:54:08
> @@ -3361,7 +3361,8 @@
> 
>  static int core_open_logs(apr_pool_t *pconf, apr_pool_t *plog,
> apr_pool_t *ptemp, server_rec *s)
>  {
> -    ap_open_logs(s, plog);
> +/* XXX */
> +    ap_open_logs(s, pconf);
>      return OK;
>  }
> 
> 
> Here is a backtrace from the coredump I got:
> 
> #0  0xff34c3d0 in apr_palloc (pool=0x7b98e0, size=24) at apr_pools.c:430
> 430         endp = active->first_avail + size;
> (gdb) where
> #0  0xff34c3d0 in apr_palloc (pool=0x7b98e0, size=24) at  apr_pools.c:430
> #1  0xff330ff8 in apr_table_make (p=0x7b98e0, nelts=5) at apr_tables.c:343
> #2  0xcdb18 in core_create_conn (ptrans=0x7b98e0, server=0x1b2ea0, csd=0x7b7910, conn_id=433,
sbh=0x7b9880) at core.c:3474
> #3  0xba9d0 in ap_run_create_connection (p=0x7b98e0, server=0x1b2ea0, csd=0x7b7910, conn_id=433,
sbh=0x7b9880) at connection.c:86
> #4  0xa089c in process_socket (p=0x7b98e0, sock=0x7b7910, my_child_num=0, my_thread_num=433)
at worker.c:560
> #5  0xa11f4 in worker_thread (thd=0x469330, dummy=0x4e2d68) at worker.c:777
> #6  0xff340990 in dummy_worker (opaque=0x469330) at thread.c:122
> (gdb) p *active
> Cannot access memory at address 0x0
> (gdb)

Hmmm, this is weird.  This means pool->active == NULL.  AFAIK this can only
happen when the pool is not really valid anymore (it got destroyed somewhere).
The reason I suspect this, is because that is the time the pool struct is
recycled (the node containing the struct is put on the freelist).  So I think
this is a lifetime problem.

Guess what?  We really need lifetime checking in debug mode.
Alternatively you could try running with APR_POOL_DEBUG turned on
and a third party tool like efence or purify.

> > (3) revert pool debug stuff and see what happens
> 
> I'll report back separately on this.
> 
> -- 
> Jeff Trawick

Thanks,

Sander


Mime
View raw message