On Thu, 4 Dec 2003, Daniel Stenberg wrote:

> For some reason, curl wrongly believes the last request
> doesn't return anything at all. I would guess that the
> bytecounter and headerbytecounter don't get updated properly
> for this case, but I that's only a guess.

I found something suspicious, but I'm not sure what the proper fix is.

For test 91 to pass, it seems important that k->ignorebody is set to TRUE on
line 861 of transfer.c (1.188). This only happens if conn->newurl isn't
NULL. From what I can see, conn->newurl is created on line 370 of http.c
(1.176). But, there's no check for NULL there in case strdup fails. I
can't see how strdup is actually failing, but maybe if data->change.url is
NULL it would be.

I put in a check for NULL after the strdup, and returned
CURLE_OUT_OF_MEMORY, but surprise surprise, it doesn't change things. There
are lots of strdup calls, and not so many checks for NULL.

This feels like uninitialized variable kind of a thing. If I set a
breakpoint that actually gets hit in gdb, the problem goes away. With that,
and --verbose and --output also making it disappear, I'm still in search of
which variable, or something more exciting like stack overflow.

I felt the urge to try making sure all pointers were set to NULL after being
free()d, but gave up when gcc gave a warning when I changed the prototype of
Curl_safefree() to take a (void **) and changed the calls to pass the
address of whatever they were passing before. I thought it would help track
this down.

Any chance this sparks an idea for someone?

-DB

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Received on 2003-12-05