On Fri, 5 Dec 2003, David Byron wrote:

Thanks for all your work on this. I still cannot repeat this problem more than
occationally, even when trying exactly the steps you use to repeat this.

> For test 91 to pass, it seems important that k->ignorebody is set to TRUE on
> line 861 of transfer.c (1.188).

Yes, that is set when the body of the retrieved data should be read but
ignored (= not sent to the write callback).

> This only happens if conn->newurl isn't NULL.

... and if newurl is non-NULL it means we should be getting that URL.

> 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 beleive I've been thinking that if strdup() returns NULL there, nothing
major will break, libcurl just won't do the correct authentication. Bad
thinking on my behalf really, we should bail out on strdup() failure.

> I can't see how strdup is actually failing, but maybe if data->change.url is
> NULL it would be.

Doing strdup(NULL) causes the memory debug system to cry out loud and exit, so
this cannot be the case if you built with --enable-debug (which I tend to
always do on my builds).

> There are lots of strdup calls, and not so many checks for NULL.

Those are all subject for fixing.

> This feels like uninitialized variable kind of a thing.

I agree.

> 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 think a stack overflow would cause a bug more easily repeatable. But I'm not
excluding the possibility.

> 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.

That would of course require you to change how Curl_safefree() is used from
~40 places too. I don't think this is a bad pointer though, as bad pointers
tend to crash harder when not used correctly. Especially when involving
free().

> Any chance this sparks an idea for someone?

I have an idea on how to proceed:

Add debug code that outputs conn->headerbytecount when it is increased. It
should be upped each time headers are read. This counter is what wrongly still
is 0 when the bug occurs. It is done on two places in
lib/transfer.c:Curl_readwrite().

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
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