httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: the most common seg fault on daedalus
Date Mon, 08 Apr 2002 16:54:47 GMT
Greg Ames wrote:
> ...looks like a problem with cleaning up an mmap bucket.  This is from
> /usr/local/apache2.0.35/corefiles/httpd.core.3 ; .4 and .5 are the same problem.
> #0  apr_pool_cleanup_kill (p=0x8152f08, data=0x8152eb8,
>     cleanup_fn=0x280cc700 <mmap_cleanup>) at apr_pools.c:1669
> #1  0x280cc90a in apr_mmap_delete (mm=0x8152eb8) at mmap.c:210
> #2  0x280ad926 in mmap_destroy (data=0x8131298) at apr_buckets_mmap.c:82

We now have dump 6 which looks the same.

Since there's no connection when the seg fault hits, I resorted to vi'ing the
dump to find the input buffers.  There definately is a common denominator:

dumps 3,4, and 6:
GET /dist/httpd/ HTTP/1.0^M
Connection: close^M
Accept: */*^M
User-Agent: Mozilla/4.7 [en] (Win98; I)^M
Range: bytes=0-^M
dump 5:
GET /dist/httpd/?C=S&O=D HTTP/1.0^M
User-Agent: Irvine/0.3.12^M
Connection: close^M
Accept: */*^M
Range: bytes=0-^M

Yes, I double checked dump 5 to verify that it contains the Elmer Fudd version
of Referer: :-)

The Range: header may be key.  Jeff tried several similar requests against
daedalus and got a 416 HTTP response code (Requested Range Not Satisfiable) each
time but no dumps.  He got a 200 against 1.3.  The Range: header looks kosher
according to RFC 2616.  I have no idea how common such a Range: header is.

Keep in mind that this is the same URL that showed that the 2.0.34 output filter
chain was busted.    
We have Multiviews processing for HEADER and README happening on top of the
mod_autoindex stuff.


View raw message