>
> I'll do a quick explain what the splays are and why the code is there and
> what's it supposed to do.

ok I understand the general idea, thanks.
(I presume this is for when using a lot of easy handles, to only deal
with the one which are likely to have something to do.)

>
> With how many easy handles in use?

I don't know. likely only one or two...

> Is this repeatable with a source code you
> can share with us?

I'm afraid it's not easy..
It's part of a big application (a videogame), and to extract a sample
that reproduces this random behaviour is a lot of work.
I hope that debugging it will be easier... ;)

>
> It certainly looks wrong that all nodes use the same key (expire time) and
> even that they are in a tree when they're identical (the [+] is used for nodes
> using the same key (time) as then they are all linked to that single node).

I think it's the very same request.
the requests that happened before at a different time.

>
> > I don't really know what splay trees are, but in Curl_splayinsert()
> > I think the case /* it already exists one of this size */
> > will produce the situation if t = Curl_splay(i,t) is the same as area.
>
> Yeah, that would cause problems. But given the explanation above, t and area
> should never be the same since 'area' would be a totally new node that is not
> already existing.

>
> If it already exists, it indicates a problem in the Curl_splayremovebyaddr()
> call done previous to the Curl_splayinsert() function in
> multi.c:Curl_expire(). Can you print the splay tree immediately before and
> after the remove call too and verify that there actually is a node removed?

well the correspoding calls from the log I sent are those tagged
curl_expire1 and
curl_expire2 .

here is a longer part of the log with the previous request that did
work for comparison.
I'll now try to get a full Curl verbose logs...

xavier