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 Host: www.apache.org^M Referer: http://www.apache.org/dist/httpd/^M User-Agent: Mozilla/4.7 [en] (Win98; I)^M Range: bytes=0-^M ^M dump 5: GET /dist/httpd/?C=S&O=D HTTP/1.0^M User-Agent: Irvine/0.3.12^M Connection: close^M Weferer: SWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOT^M Host: www.apache.org^M Accept: */*^M Range: bytes=0-^M ^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. Greg
