On Mon, 26 Jan 2009, Chad Monroe wrote:

> 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?

Yes, this problem was not introduced by you but it started to show up when the
disconnect() function was added since before then the mixup didn't matter.

> 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.

Yes. The data in 'data->state.proto' must only be stored and used during the
transfer and must not be assumed to remain after the transfer is done -
disconnect may very well be called after one or more other transfers have been
done using the same easy handle (struct SessionHandle). As you can see I
didn't see any useful data for TFTP to put there.

> 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.

Great!

-- 
  / daniel.haxx.se