reopen 449207 thanks On 11/30/07, Andrew Moise <[EMAIL PROTECTED]> wrote: > Hm, I'm not able to reproduce it with version 0.9.1-1+b1. Either > some fix made its way into that build or I'm no longer able to > reconstruct the steps that led it to seg fault. > I believe that this bug can be closed. Thanks for looking into > this; sorry that my report wasn't more productive.
... and now I can reproduce it again (or at least a similar crash-on-umount problem). If I start "valgrind --db-attach=yes curlftpfs -d -o ftpfs_debug=2,allow_other mirrors2.kernel.org /mnt/remote/debian" (with /bin/mount and /usr/bin/fusermount set non-setuid so the valgrind can work properly), and then run "find . -type f | head -n500 | xargs cat > /dev/null" in /mnt/remote/debian/LDP, then I get this error on unmount: ==29289== Thread 1: ==29289== Invalid read of size 4 ==29289== at 0x411271D: Curl_disconnect (url.c:2147) ==29289== by 0x41248AB: curl_multi_cleanup (multi.c:1541) ==29289== by 0x804A7D8: (within /usr/bin/curlftpfs) ==29289== by 0x42FC44F: (below main) (in /lib/i686/cmov/libc-2.7.so) ==29289== Address 0x6C2B138 is 0 bytes inside a block of size 12 free'd ==29289== at 0x402437F: free (vg_replace_malloc.c:233) ==29289== by 0x4115239: Curl_rm_connc (url.c:623) ==29289== by 0x4116CD9: Curl_close (url.c:446) ==29289== by 0x411FA20: curl_easy_cleanup (easy.c:513) ==29289== by 0x804A7CB: (within /usr/bin/curlftpfs) ==29289== by 0x42FC44F: (below main) (in /lib/i686/cmov/libc-2.7.so) Without valgrind, I get a glibc abort due to a double free() in what I believe is the same place. I'm not sure if this is 100% reproducible, but I've gotten it both times I tried the given reproduction steps. This is with libcurl3-dbg 7.17.1-1 and curlftpfs 0.9.1-2. This may actually be a bug in libcurl; I've looked briefly over curl's mixing of "easy" and "multi" interface use, and it all seems to be correct to me (the ftpfs.lock is always taken and curl_multi_remove_handle() called to remove the handle from the multi interface's use), whereas curl_multi_remove_handle() has some disturbing codepaths wherein it doesn't actually remove the handle, but only "remembers" the fact that it needs to be removed at a later time. That's all total guessing, though; I don't understand the code involved in either of them really at all. In any case, let me know if you can't reproduce it using the above steps; I can try to get a cleaner repro case and/or track down what's going on in more detail if need be. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
