On Jan 26, 2009, at 2:43 PM, Daniel Stenberg wrote:

> On Fri, 16 Jan 2009, Chad Monroe wrote:
>
>> I'm not sure how I missed test cases 2003 and 2004, but I installed
>> libssh2 so I could run them and can reproduce the same issues you
>> see. I know what is causing the problems, just not a good way to
>> fix them.
>
> Thanks for your work. I fixed the remaining problems and committed
> the lot just now.
>
> The problem was that we allocated connection-oriented data in the
> wrong struct, so the data was re-used by the handle for other
> connections. I simply made the tftp state struct get associated from
> the 'connectdata' struct instead and all problems were gone!
>
> --
>
> / daniel.haxx.se

Hi Daniel,

Thanks again for the help with this. I just looked at the CVS logs and
see where I went wrong. It seems like this has been a flaw in the TFTP
portion of libcurl all along (tftp_connect() has always allocated
tftp_state_data_t to conn->data->state.proto.tftp) if I see things
right? conn->data->state.proto.tftp is the struct with handle specific
data (ie may be re-used for multiple connections) where as conn-
>proto.tftpc is connection specific and is allocated/free'd for each
connection, right? I'm just trying to better understand how these
modules work for future fixes.

I'll merge the changes from the libcurl CVS head into my sandbox and
finish up testing of my multi fix. If all goes well I'll submit a
patch which will update the TFTP multi interface to support
asynchronous operation in the next few days. Thanks again!

--
Chad Monroe