httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject chunked input core dump on daedalus
Date Thu, 01 Nov 2001 20:30:16 GMT
We had a seg fault last night, and got another 500M+ core dump that
somewhat resembles the pipelined POST dumps we had a few days ago.  But
in this case, the HTTP_IN filter is in place.  Here are the input
buffers:

GET /index.html HTTP/1.1
User-Agent: Profile/MIDP-1.0 Configuration/CLDC-1.0
Transfer-Encoding: chunked
Host: www.apache.org:80
 
4
11^
 
0

The chunked body is the interesting bit, but hard to see in that
format.  With escaped CRs and LFs:

"4\r\n"
"11^\n"
"\r\n"
"0\r\n"
"\r\n"

This looks legal.  http_filter's ctx: 
(gdb) p *ctx
$10 = {remaining = 1, state = BODY_CHUNK}

Our magic overloaded mode field:

(gdb) p *readbytes
$12 = -3

core_input_filter thinks this means "read a block, no more than -3
long", and ends up trying to partition at offset -3.  I believe the
whole thing was looping, possibly driven by  ap_get_client_block, until
we run out of memory and seg fault.  

I suspect we had something fubar'ed (like *readbytes == 0) when we read
the chunk body ( "11^\n" ) , stripped the \n off the end, decided we
read 3 bytes, and decremented the counters by 3.

The dump is /usr/local/apache2_0_27/corefiles/httpd.core.1 .

Greg
--------------------------------------------------------

#0  apr_palloc (a=0x812500c, reqsize=12) at apr_pools.c:1251
#1  0x280a8687 in apr_brigade_create (p=0x812500c) at apr_brigade.c:104
#2  0x280a86d9 in apr_brigade_split (b=0x81253a4, e=0x808e060)
    at apr_brigade.c:119
#3  0x8073b1d in core_input_filter (f=0x8125364, b=0x81917dc,
    mode=AP_MODE_BLOCKING, readbytes=0xbfbfb750) at core.c:2898
#4  0x806cf35 in ap_get_brigade (next=0x8125364, bb=0x81917dc,
    mode=AP_MODE_BLOCKING, readbytes=0xbfbfb750) at util_filter.c:250
#5  0x805d2c5 in ap_http_filter (f=0x8191a94, b=0x81917dc,
    mode=AP_MODE_BLOCKING, readbytes=0xbfbfb750) at http_protocol.c:585
#6  0x806cf35 in ap_get_brigade (next=0x8191a94, bb=0x81917dc,
    mode=AP_MODE_BLOCKING, readbytes=0xbfbfb750) at util_filter.c:250
#7  0x805e537 in ap_get_client_block (r=0x819103c,
    buffer=0xbfbfb788 "11^\nrces2-j/images/dot.gif, ", bufsiz=8192)
    at http_protocol.c:1377
#8  0x805e72f in ap_discard_request_body (r=0x819103c) at
http_protocol.c:1469
#9  0x80735bc in default_handler (r=0x819103c) at core.c:2701
#10 0x806307f in ap_run_handler (r=0x819103c) at config.c:185
#11 0x8063617 in ap_invoke_handler (r=0x819103c) at config.c:344
#12 0x80606e5 in ap_process_request (r=0x819103c) at http_request.c:286
#13 0x805c472 in ap_process_http_connection (c=0x8125114) at
http_core.c:289
#14 0x806b5f7 in ap_run_process_connection (c=0x8125114) at
connection.c:82
#15 0x806b7b5 in ap_process_connection (c=0x8125114) at connection.c:219
#16 0x8061c74 in child_main (child_num_arg=45) at prefork.c:831
#17 0x8061dca in make_child (s=0x8095974, slot=45) at prefork.c:918
#18 0x806201d in perform_idle_server_maintenance (p=0x809500c)
    at prefork.c:1059
#19 0x80623e2 in ap_mpm_run (_pconf=0x809500c, plog=0x80ce00c,
s=0x8095974)
    at prefork.c:1238
#20 0x8067641 in main (argc=1, argv=0xbfbffb5c) at main.c:432
#21 0x805c03d in _start ()

Mime
View raw message