I just noticed that we had a seg fault on Dec. 2. The dump is now in /usr/local/apache2.0.43b/corefiles/httpd.core.2

(gdb) bt
#0 ap_escape_html (p=0x8152018,
s=0x8158018 "Cookie: ASPSESSIONIDGQGQGTHO=FDLGHGOBJJJNPCKBHGOGAFFP; DTMLASTPOPUP=%7Bts+%272002%2D12%2D02+22%3A39%3A34%27%7D; CFTOKEN=16145632; VJ UTrackID=66.200.155.34.14801038898591969; AFFILIATE_SCOPE=N; ASPSES"...) at util.c:1703
#1 0x8075025 in ap_get_mime_headers_core (r=0x8152050, bb=0x8152d28)
at protocol.c:781
#2 0x80753f7 in ap_read_request (conn=0x8142128) at protocol.c:947
#3 0x8060056 in ap_process_http_connection (c=0x8142128) at http_core.c:312
#4 0x80711db in ap_run_process_connection (c=0x8142128) at connection.c:85
#5 0x80714f0 in ap_process_connection (c=0x8142128, csd=0x8142050)
at connection.c:207
#6 0x80664e4 in child_main (child_num_arg=131) at prefork.c:696

line 1703 of server/util.c:
1703 x[j] = s[i];

(gdb) p i
$4 = 37872
(gdb) p j
$5 = 38016

hmmmm, odd. I thought we had an 8k-or-so limit on input line size. Plus, there's code at the beginning of this function to calculate the amount of memory to palloc for x.

Greg



Reply via email to