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.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
