apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: pool problems with HEAD??
Date Thu, 10 Jan 2002 17:53:26 GMT
Jeff Trawick <trawick@attglobal.net> writes:

> Aaron Bannert <aaron@clove.org> 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 | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Mime
View raw message