On Tue, 1 Jun 2004, Alexander Krasnostavsky wrote:

> OK. Now I understand. The problem appeared within my patch. For 3rd party
> transfer, there is a need to keep 2 'data' structs (SessionHandle), one for
> each connection.

I disagree. There's no "need" to have two such structs. It is however the way
you opted to write your code. The SessionHandle struct is the base curl handle
struct and it is fairly big (30-40K or something), I think we should be more
restrictive.

> So in ConnectionExists(), if there is more than one open connection,
> conn_temp will be pointed to some connection in data->state.connects, but
> the 'data' won't be the same.

Then you've altered the whole concept of connection reuse and I'd say you are
out on very deep water. I wouldnt't go swimming in those places! ;-)

I suggest you find an alternative way of doing this. We cannot have
cached/re-used connections over multiple SessionHandle structs (at least not
without much more careful planning and usage of the share interface concepts).

> Therefore refreshing the user data ('set' struct) in the primary connection
> will solve the problem. Do you have any other way to handle this?

You're hitting exactly the problem I mentioned when I noticed that you cloned
the data struct and assume that things will work fine from there on. Since the
code doesn't know if it works on a clone or on the original struct, it can't
work correctly and will end up free()ing pointers twice and similar.

I can't see how you can easily work around this problem when you clone the
data struct.

-- 
     Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
      Dedicated custom curl help for hire: http://haxx.se/curl.html