[Issue #2 Update] RE: coredump backtraces

[Cliff Woolley <cl...@yahoo.com>]

> httpd.core.4 is a failed bucket assert:
> (gdb) bt
> #2  0x80683ee in ap_log_assert (
>     szExp=0x80964e0 "(((&(req_cfg->bb)->list))->next == (struct apr_bucket
> *)((char *)((&(req_cfg->bb)->list)) - ((size_t)(&((struct apr_bucket *)0)->
> link))))", szFile=0x80962e0 "http_protocol.c", nLine=2722) at log.c:562
> #3  0x8060004 in ap_setup_client_block (r=0x81ca03c, read_policy=2)
>     at http_protocol.c:2722
> #4  0x80602f5 in ap_discard_request_body (r=0x81ca03c) at http_protocol.c:2868
> #5  0x805bb4e in default_handler (r=0x81ca03c) at http_core.c:2975

Just wanted to update you all on this.

I spent some time yesterday investigating this issue with gdb.  The assert just
checks to make sure that req_cfg->bb is an empty brigade, which, obviously, it
wasn't.  More specifically, it turns out that the brigade had one bucket in it:
a zero-length heap bucket.  So somewhere there's a way to return (presumably
from ap_getline()) without cleaning out req_cfg->bb first.  The heap bucket
itself is kind of interesting... it's not just a newly-created zero-length
bucket, because the start and end pointers both reference byte 58 of the data,
implying that the bucket originally had 58 bytes in it which were then consumed.
Unsurprisingly, those 58 bytes are "GET /images/apache_pb.gif HTTP/1.0\r\nHost:
www.apache.org\r\n".

I hope to be able to track this down in ap_getline(), but if anyone has ideas
right off, they'd be welcome.  If anyone wants to see a dump of the relevant
data structures from the corefile, let me know and I'll forward a transcript of
my gdb session to you.

--Cliff