Chad Monroe wrote:
On Feb 11, 2009, at 2:04 AM, Daniel Stenberg wrote:
On Tue, 10 Feb 2009, Chad Monroe wrote:
I'm finishing up testing of my TFTP multi code but have one
question. When using the easy interface, tftp_disconnect() gets
called properly via close_connections() in Curl_close() which is
what curl_easy_cleanup() calls. In the case of the multi interface,
tftp_disconnect() never gets called, leading to a ~4Kb memory leak
on handle deletion.
That sounds strange. When the multi interface is used, the connection
cache is owned by the multi handle so thus tftp_disconnect() should
be called when the connection cache is cleared, which should should
happen when you call curl_multi_cleanup(). Unless the connection
didn't fit in the cache due to size restraints, but then the
connection should get disconnected immedately after the transfer was
done.
Looking at curl_multi_cleanup(), it seems I need to add PROT_TFTP to
the PROT_CLOSEACTION mask in urldata.h. This solves my problem, but
is it the correct fix?
No it isn't. That PROT_CLOSEACTION is meant for protocol actions
necessary when a connection is to be disconnected, which so far FTP
is the only one as it wants a "QUIT" command issued.
Anyway, if you post your current work/patch perhaps we can help out
better!
--
/ daniel.haxx.se
Hi,
Sorry for the much delayed response. Here is the diff (I'm still based
on curl 7.19.2) between my modified source directory and the original.
Everything related to CURLOPT_TFTPBLKSIZE has been committed to CURL
CVS and is in curl 7.19.3, so it can be ignored. Other than the above
issue this multi code has been heavily tested on many of our embedded
platforms for TFTP RRQ (I have not tested WRQ yet). Once this issue is
resolved I'll run through all of the test cases and such and submit a
patch against a more recent version of CURL. Thanks again!
--
Chad Monroe
Hi All,
I'm not sure if this just got overlooked or if there was something wrong
with my submission but I haven't seen any responses as of yet. If anyone
has any input it'd be greatly appreciated!
--
Chad Monroe
