can you run it with efence/purify on ?
this should catch the problem.
Jeff Trawick wrote:
> Jeff Trawick <[EMAIL PROTECTED]> writes:
>
>
>>Aaron Bannert <[EMAIL PROTECTED]> writes:
>>
>>
>>>On Thu, Jan 10, 2002 at 11:28:47AM -0500, Jeff Trawick wrote:
>>>
>>>>CVS HEAD, Solaris, worker MPM, one process with many threads
>>>>
>>>Sander just suggested that you might try reverting David's
>>>plog/pconf patch. (Sander had to run and asked me to post this).
>>>
>>Thanks for the quick feedback guys!
>>
>>
>>>I'm looking into other possibilities of pool mismanagement in
>>>mod_log_config as well.
>>>
>>I'm going to try this sequence:
>>
>>(1) turn off mod_log_config/access_log and see what happens
>>
>
> I commented out the one CustomLog and tried again (still Solaris,
> current code):
>
> Loaded symbols for /usr/lib/libthread.so.1
> #0 0xff1618a8 in memset () from /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
> (gdb) where
> #0 0xff1618a8 in memset () from /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
> #1 0xff34c56c in apr_pcalloc (pool=0x5d9ce0, size=24) at apr_pools.c:473
> #2 0xff330880 in make_array_core (res=0xffffffff, p=0x5d9ce0, nelts=5, elt_size=4,
>clear=1) at apr_tables.c:103
> #3 0xff33092c in apr_array_make (p=0x5d9ce0, nelts=5, elt_size=4) at
>apr_tables.c:121
> #4 0x4e2cc in fixup_vary (r=0x7a00d0) at http_protocol.c:1099
> #5 0x4e630 in ap_http_header_filter (f=0x5e2310, b=0x5e2430) at http_protocol.c:1189
> #6 0xbe208 in ap_pass_brigade (next=0x5e2310, bb=0x5e2430) at util_filter.c:388
> #7 0xc2dd4 in ap_content_length_filter (f=0x5e22f8, b=0x5e2430) at protocol.c:1010
> #8 0xbe208 in ap_pass_brigade (next=0x5e22f8, bb=0x5e2430) at util_filter.c:388
> #9 0x51bc0 in ap_byterange_filter (f=0x5e22e0, bb=0x5e2430) at http_protocol.c:2414
> #10 0xbe208 in ap_pass_brigade (next=0x5e22e0, bb=0x5e2430) at util_filter.c:388
> #11 0xcb918 in default_handler (r=0x7a00d0) at core.c:2815
> #12 0xa5f6c in ap_run_handler (r=0x7a00d0) at config.c:185
> #13 0xa6be4 in ap_invoke_handler (r=0x7a00d0) at config.c:359
> #14 0x53908 in ap_internal_redirect (new_uri=0x7a00c0 "/index.html.en", r=0x5d9d18)
>at http_request.c:454
> #15 0x8bd34 in handle_map_file (r=0x5d9d18) at mod_negotiation.c:2838
> #16 0xa5f6c in ap_run_handler (r=0x5d9d18) at config.c:185
> #17 0xa6be4 in ap_invoke_handler (r=0x5d9d18) at config.c:359
> #18 0x531bc in ap_process_request (r=0x5d9d18) at http_request.c:292
> #19 0x4b150 in ap_process_http_connection (c=0x5d7e58) at http_core.c:280
> #20 0xba72c in ap_run_process_connection (c=0x5d7e58) at connection.c:84
> #21 0xbace4 in ap_process_connection (c=0x5d7e58) at connection.c:230
> #22 0xa08bc in process_socket (p=0x5d7d38, sock=0x5d7d70, my_child_num=0,
>my_thread_num=458) at worker.c:562
> #23 0xa11f4 in worker_thread (thd=0x469650, dummy=0x4e2fc0) at worker.c:777
> #24 0xff340990 in dummy_worker (opaque=0x469650) at thread.c:122
> (gdb)
>
>
>>(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)
>
>
>
>>(3) revert pool debug stuff and see what happens
>>
>
> I'll report back separately on this.
>
>
