Cliff Woolley wrote:
>
> On Thu, 8 Mar 2001, Jeff Trawick wrote:
>
> > An assert pops in ap_getline(). The assert attempts to verify that
> > the brigade is empty once we've read an entire line. In this case
> > however an eos bucket is still in the brigade.
>
> That's the same one seen in corefiles 4 and 9 on daedalus. It's not
> always an EOS bucket, though. In corefile 4, it's an empty heap bucket.
> In corefile 9, it's a 10-byte heap bucket. Clearly something screwy is
> going on.
>
core dump #12 is another newer one. Jeff & I stared at it for quite a
while. Unfortunately, staring didn't make it go away, but I think we
learned a little.
This one has a one byte heap bucket containing "m", with no other
printable characters in front of the "m" in storage. The URL is
/xml.apache.org/cocoon/resources/line.gif which exists (hard to see on a
browser, it's a 5 pixel vertical line). Currently, r->headers_in
contains two headers:
(gdb) dump_table r->headers_in
[0] 'Host'='xml.apache.org'
[1] 'User-Agent'='Mozilla/4.0 (compatible; MSIE 5.0; Windows NT 5.0)
Opera 5.02 [de]'
...but, Jeff found what looks like the original input buffer (by editing
the core file) which has many more headers. hmmmm....
I backed up into get_mime_headers because I wanted to move the assert as
early as possible after reading the headers. Right after the end of the
header loop, I see:
apr_table_overlap(r->headers_in, tmp_headers,
APR_OVERLAP_TABLES_MERGE);
hmmm....I wonder if this is failing intermittently, and clobbering
stuff? I know that somebody fixed a hash expansion bug recently, but
diving into to apr_table_overlap code, I didn't get there. Does anyone
know off the top of their head if this does invoke the code that had the
expansion bug?
In any case, I put debug asserts on either side of that line, and I'm
about to build it on apache.org, using the newest 2_0_14 tarball.
Greg
