httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject daedalus coredump from 2.0.35c
Date Tue, 09 Apr 2002 19:01:53 GMT
(this one has a long backtrace, so I'll save that for last.)

I should mention that there were a bunch of seg faults within a minute or two,
then nothing.  

Here are the input buffers:

(gdb)  printf "%20s",((core_net_rec *)f.ctx).client_socket.head.data
GET /docs/cygwin.html HTTP/1.1
Host: httpd.apache.org
Accept: */*
Referer: http://httpd.apache.org/docs/
User-Agent: NetAnts/1.25
Pragma: no-cache
Cache-Control: no-cache
Connection: close
Range: bytes=20480-

Notice the last two headers.  We had a similar combination in the dumps from
this weekend, except that they had Range: bytes=0- .

NetAnts' web page says it is a download manager with several connections each
downloading a small piece of the file.  That may explain why the seg faults were
clustered in time.

(gdb) p r->status_line
$3 = 0x8084280 "416 Requested Range Not Satisfiable"

hmmm, that's what Jeff was getting yesterday with hand generated byterange
requests using the Range: header we saw in the dumps, and we don't have an
explanation for that yet.  Since this one is asking for a non-zero starting
value, it could be a legit 416.  But when my browser request that page, I get
Content Length: 20603, so this 416 looks bogus as well.

core_output_filter is choking on an apr_bucket_read.  Its brigade looks pretty
complicated for an error page, but mod_include is filtering it, fwiw.

(gdb) dump_brigade b
dump of brigade 0x812c6a8
   0: bucket=HEAP(0x81311e8), length=207, data=0x8131558
   1: bucket=TRANSIENT(0x81315b0), length=5, data=0xbfbfe894
   2: bucket=HEAP(0x81310e0), length=389, data=0x8131138
   3: bucket=IMMORTAL(0x8131608), length=2, data=0x8083db9
   4: bucket=IMMORTAL(0x8131660), length=5, data=0x8083dbc
   5: bucket=EOS(0x8131298), length=0, data=0x0
   6: bucket=(0x814fefc), length=135590000, data=0x280adea0

(gdb) p *bucket
$4 = {link = {next = 0x812c6ac, prev = 0x8131298}, type = 0x8131010,
  length = 135590000, start = 2885363290195951352, data = 0x280adea0,
  free = 0x8159010, list = 0x8131190}
(gdb) p *bucket.type
$5 = {name = 0x8095900 "\001", num_func = 0, destroy = 0x8131000, read = 0,
  setaside = 0x58, split = 0x8131010, copy = 0x8131000}

I'm going to play with byterange requests on my ThinkPad and see if strange
stuff happens there too. I'm assuming there is no httpd test for "n-"
byteranges?

Greg
----------------------------------------------------------------------------------------
(gdb) bt
#0  0x0 in ?? ()
#1  0x8078ab5 in core_output_filter (f=0x812c3d8, b=0x812c6a8) at core.c:3737
#2  0x8070cb1 in ap_pass_brigade (next=0x812c3d8, bb=0x8156fb8) at
util_filter.c:534
#3  0x805e937 in chunk_filter (f=0x8150088, b=0x8156fb8) at http_core.c:260
#4  0x8070cb1 in ap_pass_brigade (next=0x8150088, bb=0x8156fb8) at
util_filter.c:534
#5  0x8060d5e in ap_http_header_filter (f=0x8159808, b=0x8156fb8)
    at http_protocol.c:1474
#6  0x8070cb1 in ap_pass_brigade (next=0x8159808, bb=0x8156fb8) at
util_filter.c:534
#7  0x8073152 in ap_content_length_filter (f=0x81597f0, b=0x8156fb8)
    at protocol.c:1232
#8  0x8070cb1 in ap_pass_brigade (next=0x81597f0, bb=0x8156fb8) at
util_filter.c:534
#9  0x281e3bbb in handle_include (ctx=0x812c600, bb=0xbfbfeef4, r=0x8159048,
    f=0x8156468, head_ptr=0x81310e0, inserted_head=0xbfbfeaa0) at
mod_include.c:1250
#10 0x281e69c1 in send_parsed_content (bb=0xbfbfeef4, r=0x8159048, f=0x8156468)
    at mod_include.c:3109
#11 0x281e7256 in includes_filter (f=0x8156468, b=0x8156fb8) at
mod_include.c:3387
#12 0x8070cb1 in ap_pass_brigade (next=0x8156468, bb=0x8156fb8) at
util_filter.c:534
#13 0x8073433 in ap_old_write_filter (f=0x8156fa0, bb=0x814f060) at
protocol.c:1333
#14 0x8070cb1 in ap_pass_brigade (next=0x8156fa0, bb=0x814f060) at
util_filter.c:534
#15 0x8072b17 in end_output_stream (r=0x8159048) at protocol.c:995
#16 0x8072b7b in ap_finalize_request_protocol (r=0x8159048) at protocol.c:1016
#17 0x80620e0 in ap_send_error_response (r=0x8159048, recursive_error=0)
#18 0x806332f in ap_die (type=416, r=0x8159048) at http_request.c:205
#19 0x8060d0d in ap_http_header_filter (f=0x8159808, b=0x8156f48)
    at http_protocol.c:1325
#20 0x8070cb1 in ap_pass_brigade (next=0x8159808, bb=0x8156f48) at
util_filter.c:534
#21 0x807327b in ap_content_length_filter (f=0x81597f0, b=0x8156f48)
    at protocol.c:1264
#22 0x8070cb1 in ap_pass_brigade (next=0x81597f0, bb=0x8156f48) at
util_filter.c:534
#23 0x8062e45 in ap_byterange_filter (f=0x81597d8, bb=0x8156558)
    at http_protocol.c:2760
#24 0x8070cb1 in ap_pass_brigade (next=0x81597d8, bb=0x8156558) at
util_filter.c:534
#25 0x281e3bbb in handle_include (ctx=0x812c600, bb=0xbfbff734, r=0x8159048,
    f=0x8156468, head_ptr=0x8131088, inserted_head=0xbfbff2e0) at
mod_include.c:1250
#26 0x281e69c1 in send_parsed_content (bb=0xbfbff734, r=0x8159048, f=0x8156468)
    at mod_include.c:3109
#27 0x281e7256 in includes_filter (f=0x8156468, b=0x8156558) at
mod_include.c:3387
#28 0x8070cb1 in ap_pass_brigade (next=0x8156468, bb=0x8156558) at
util_filter.c:534
#29 0x8077fa2 in default_handler (r=0x8159048) at core.c:3247
#30 0x8065eef in ap_run_handler (r=0x8159048) at config.c:193
#31 0x806648f in ap_invoke_handler (r=0x8159048) at config.c:373
#32 0x8063413 in ap_process_request (r=0x8159048) at http_request.c:261
#33 0x805e9db in ap_process_http_connection (c=0x812c120) at http_core.c:291
#34 0x806ecf3 in ap_run_process_connection (c=0x812c120) at connection.c:85
#35 0x806f008 in ap_process_connection (c=0x812c120, csd=0x812c048)
    at connection.c:207
#36 0x80648f0 in child_main (child_num_arg=165) at prefork.c:671
#37 0x8064a5a in make_child (s=0x809dd60, slot=165) at prefork.c:765
#38 0x8064c45 in perform_idle_server_maintenance (p=0x809c010) at prefork.c:900
#39 0x8065022 in ap_mpm_run (_pconf=0x809c010, plog=0x80c6010, s=0x809dd60)
    at prefork.c:1092
#40 0x806a8dd in main (argc=1, argv=0xbfbffb5c) at main.c:622
#41 0x805e5c5 in _start ()

Mime
View raw message