Bug#449207: Status

["Andrew Moise" <chops@demiurgestudios.com>]

  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!