Hey David, I missed your message -- you should send it to the submitter address as well as to the bug address :-). Anyway, I am still seeing flakiness in curlftpfs 0.9.1-3+b1 with curl 7.18.0-1. When I ran the test case I descibed a single time, I got this on exit:
==11219== Invalid read of size 4 ==11219== at 0x4113F29: Curl_disconnect (url.c:2182) ==11219== by 0x412669B: curl_multi_cleanup (multi.c:1536) ==11219== by 0x804A7D8: (within /usr/bin/curlftpfs) ==11219== by 0x431F44F: (below main) (in /lib/i686/cmov/libc-2.7.so) ==11219== Address 0xa5e04c8 is 0 bytes inside a block of size 12 free'd ==11219== at 0x402265C: free (vg_replace_malloc.c:323) ==11219== by 0x4116BE9: Curl_rm_connc (url.c:630) ==11219== by 0x4118489: Curl_close (url.c:456) ==11219== by 0x4121270: curl_easy_cleanup (easy.c:523) ==11219== by 0x804A7CB: (within /usr/bin/curlftpfs) ==11219== by 0x431F44F: (below main) (in /lib/i686/cmov/libc-2.7.so) ... which looks like the same misbehavior. I'm actually running curlftpfs in production and suffering from some flakiness; this isn't the problem that I'm experiencing, but it's all I've been able to pin down into a single reproducible case, and I have a feeling that it may be related to the flakiness I'm experiencing. In any case, if I discover anything related to this bug while attacking the bug that is actually causing me problems (or if I'm able to pin down my problems to an easily described and reproducible case), I'll let you know. Thanks for the followup! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
