[...]
> > (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
