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 16:47:15 GMT
Jeff, I'm going over the pools code right now.
I'm wondering if something slipped in when I checked in
the APR_POOL_DEBUG code (*grunt*)

Could you do me a favor and try with one rev earlier
to see if it has the same problem?  In the mean time
I'll try and track it down.

Sander


> -----Original Message-----
> From: trawick@rdu163-40-092.nc.rr.com
> [mailto:trawick@rdu163-40-092.nc.rr.com]On Behalf Of Jeff Trawick
> Sent: 10 January 2002 17:29
> To: dev@apr.apache.org; dev@httpd.apache.org
> Subject: pool problems with HEAD??
> 
> 
> CVS HEAD, Solaris, worker MPM, one process with many threads
> 
> <IfModule worker.c>
> ServerLimit         1
> ThreadLimit         500
> StartServers         1
> MaxClients         500
> MinSpareThreads     25
> MaxSpareThreads     75
> ThreadsPerChild     500
> MaxRequestsPerChild  0
> </IfModule>
> 
> I had a client with many concurrent connections continually doing the
> same request over and over.
> 
> After starting another client to get another 200 or so concurrent
> connections, I quickly got a segfault in mod_log_config because
> supposedly apr_palloc returned some bogus addresses (0 and 0x38).
> 
> #0  0x3fd84 in config_log_transaction (r=Cannot access memory at
>  address 0xed5018f4
> ) at mod_log_config.c:823
> 823             strs[i] = process_item(r, orig, &items[i]);
> (gdb) p strs
> $1 = (char **) 0x0
> (gdb) p format->nelts
> $2 = 14
> (gdb) p strl
> $4 = (int *) 0x38
> (gdb) p i
> $5 = 0
> (gdb)
> (gdb) where
> #0  0x3fd84 in config_log_transaction (r=0x6a62c8, cls=0x1add38,
>  default_format=0x15cde8)
>     at mod_log_config.c:823
> #1  0x3ffd4 in multi_log_transaction (r=0x6a2618) at
>  mod_log_config.c:881
> #2  0xc3f98 in ap_run_log_transaction (r=0x6a2618) at protocol.c:1297
> #3  0x53228 in ap_process_request (r=0x6a2618) at http_request.c:315
> #4  0x4b150 in ap_process_http_connection (c=0x6a0758) at
>  http_core.c:280
> #5  0xba72c in ap_run_process_connection (c=0x6a0758) at
>  connection.c:84
> #6  0xbace4 in ap_process_connection (c=0x6a0758) at connection.c:230
> #7  0xa08bc in process_socket (p=0x6a0638, sock=0x6a0670,
>  my_child_num=0, my_thread_num=187)
>     at worker.c:562
> #8  0xa11f4 in worker_thread (thd=0x2bef88, dummy=0x1163b0) at
>  worker.c:777
> #9  0xff340990 in ?? ()
> 
> The funkiness about r changing in the traceback is (I suspect) because
> in multi_log_transaction we walked through a list of r's using the
> parameter as the variable.  Both r's look healthy.
> 
> Running a level of code from about a day before 2.0.30 on AIX this
> morning, running about the same worker MPM config, I got a segfault
> down in apr_palloc() because some heap structures were messed up.
> 
> Has anybody pounded on an Apache configured like that (one process,
> many threads)?
> 
> -- 
> 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