On Mon, 29 May 2006, Xavier Bouchoux wrote:

Thanks for your patience and persistance, but we're progressing slowly...

> I did a cvs update, as I saz you added more debug info.
> and the error log does trigger:
>
> SPLAY curl_expire1<<<
> SPLAY curl_expire1>>>
> * Internal error clearing splay node = 1

Nice! It's good to see that we're now at least start to understand somewhat of
what the sympthoms are when the failures have happened.

> It seems the crashing scenario is that
> req1 is launched
> req2 is launched
> --> at this point the splay tree only contains one entry while
> two req are live.

That certainly seems wrong. Can you make sure that Curl_expire() really isn't
called at all for the req1 ?

Or am I misinterpreting your debug logs? Were they actually in cronological
order? Did the "internal error" happen _before_ the "req1 is launched" ?

> req2 finished
> ---> at this point the splay tree is empty, while req1 is still live.

Badness.

> req1 finishes
> --> oops the splay tree doesn't contain it

And the shear fact that it tries to remove it shows that the 'timeval' is
filled in for the splay tree node, which should only be the case if it truly
was added to the tree.

Is the req1 handle that shows this problem re-used from a previous request?
Could it be so simple that it contains "rubbish" in that struct from the past
request? I can't really see how that happens though, as Curl_expire() is
called with a 0 time (to signal removal from the splay tree) in both
Curl_done() and Curl_disconnect()...

> req3 is launched
> -> the looped tree is produced

I suspect this is just a problem that follows the mess done previous to this
point.

> Maybe an other cause of the problem is that req1 and req2 both connect
> to the same server ip but with a different port. (443 and 80)

I don't think so, they still have their own easy handle and separate data.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html