> But if a pointer like this is "randomly" set to NULL during execution, it
is a
> sign of something really seriously broken. Wouldn't it then make better
sense
> to just bail out really hard with a fatal error? That's a pointer that
should
> be set after connect in the first request of a connection and all
subsequent
> requests should be able to read it.

I second your opinion that its better to find a reproduceable scenario and
fix the root of the problem rather than protecting from the outcomes of the
issue. However, I haven't yet been able to consistently reproduce it. I'll
keep on trying. As I said when it happens it is likely to occur when
connections are reused. Perhaps under such circumstances the previous state
is not properly cleared? The 'this_is_a_follow' flag seems to be cleared in
Curl_pretransfer, yet the 'first_host' field is never cleared only assigned
to (in http.c:1386). Can it be that when reusing connections
'this_is_a_follow' is properly handled, while 'first_host' isn't?

> Have you tried using valgrind and/or libcurl's memory debug system or
similar
> to see if you could detect any memory usage badness?
>
> It could in fact also be your application causing this.
While this is always true :) I can assure you that it doesn't look like a
memory corruption problem. The entire data structures look clean and
consistent.

Cheers,
Shmul
Received on 2007-01-29