Bug 595434
| Summary: | A bug cause curlftpfs hang. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Kirby Zhou <kirbyzhou> |
| Component: | curl | Assignee: | Kamil Dudka <kdudka> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.5 | ||
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-08-05 21:55:07 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Kirby Zhou
2010-05-24 15:38:18 UTC
(In reply to comment #0) Thank you for filling the bug! Are you able to narrow down the problem to curl only example? > curlftpfs hangs when it is linked with curl 7.15.5, 7.19.6 is OK. We are definitely not going to update curl in el5, not even in order to make curlftps working. From what I know we don't support curlftpfs at all. > Problem downloading 2 zero byte files with FTP > https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1618359&group_id=976 I am not able to repeat the problem above with curl-7.15.5-9.el5. Did you try it yourself actually? To narrow is difficult, I have not read the code of fuse-curlftpfs ever. Here is my scene: I mount a ftp mirror of RHEL4AS.x86_64 source dvd, then do yum-arch with it, then hang. ps aux | fgrep curlftpfs root 18518 0.0 0.0 83516 2524 ? Ssl 00:12 0:00 curlftpfs -oro,connect_timeout=2 ftp.no.sohu.com/pub/os/Linux/RedHat/enterprise/x86_64/4AS/SRPMS.os /media/4AS.x86_64/SRPMS.os ~]# ps aux | fgrep yum-arch root 18533 0.0 0.5 199812 13632 pts/0 S+ 00:12 0:00 /usr/bin/python /usr/bin/yum-arch -q -l /srv/yum/yum/repo.ossrc/rhel4AS.src ~]# gstack `pgrep curlftpfs` Thread 4 (Thread 0x41cbc940 (LWP 18519)): #0 0x00000034522cced2 in select () from /lib64/libc.so.6 #1 0x0000000000403937 in ftpfs_read_chunk () #2 0x0000000000403c6b in ftpfs_read () #3 0x0000003452e0e498 in ?? () from /lib64/libfuse.so.2 #4 0x0000003452e0ff19 in ?? () from /lib64/libfuse.so.2 #5 0x0000003452e0f097 in ?? () from /lib64/libfuse.so.2 #6 0x0000003452a064a7 in start_thread () from /lib64/libpthread.so.0 #7 0x00000034522d3c2d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x426bd940 (LWP 18520)): #0 0x0000003452a0d5cb in read () from /lib64/libpthread.so.0 #1 0x0000003452e0ecaa in ?? () from /lib64/libfuse.so.2 #2 0x0000003452e0f034 in ?? () from /lib64/libfuse.so.2 #3 0x0000003452a064a7 in start_thread () from /lib64/libpthread.so.0 #4 0x00000034522d3c2d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x430be940 (LWP 18749)): #0 0x0000003452a0d5cb in read () from /lib64/libpthread.so.0 #1 0x0000003452e0ecaa in ?? () from /lib64/libfuse.so.2 #2 0x0000003452e0f034 in ?? () from /lib64/libfuse.so.2 #3 0x0000003452a064a7 in start_thread () from /lib64/libpthread.so.0 #4 0x00000034522d3c2d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x2b4f05226420 (LWP 18518)): #0 0x0000003452a0c9b1 in sem_wait () from /lib64/libpthread.so.0 #1 0x0000003452e0f235 in fuse_session_loop_mt () from /lib64/libfuse.so.2 #2 0x0000003452e130b4 in ?? () from /lib64/libfuse.so.2 #3 0x0000000000402a36 in main () It is not always hang, 70% chance you hit. (In reply to comment #2) > To narrow is difficult, I have not read the code of fuse-curlftpfs ever. The bug is open against curl. If you are not able to show us a bug in curl, we are most likely not able to fix it. > ~]# gstack `pgrep curlftpfs` > Thread 4 (Thread 0x41cbc940 (LWP 18519)): > #0 0x00000034522cced2 in select () from /lib64/libc.so.6 > #1 0x0000000000403937 in ftpfs_read_chunk () > #2 0x0000000000403c6b in ftpfs_read () > #3 0x0000003452e0e498 in ?? () from /lib64/libfuse.so.2 > #4 0x0000003452e0ff19 in ?? () from /lib64/libfuse.so.2 > #5 0x0000003452e0f097 in ?? () from /lib64/libfuse.so.2 > #6 0x0000003452a064a7 in start_thread () from /lib64/libpthread.so.0 > #7 0x00000034522d3c2d in clone () from /lib64/libc.so.6 > Thread 3 (Thread 0x426bd940 (LWP 18520)): > #0 0x0000003452a0d5cb in read () from /lib64/libpthread.so.0 > #1 0x0000003452e0ecaa in ?? () from /lib64/libfuse.so.2 > #2 0x0000003452e0f034 in ?? () from /lib64/libfuse.so.2 > #3 0x0000003452a064a7 in start_thread () from /lib64/libpthread.so.0 > #4 0x00000034522d3c2d in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x430be940 (LWP 18749)): > #0 0x0000003452a0d5cb in read () from /lib64/libpthread.so.0 > #1 0x0000003452e0ecaa in ?? () from /lib64/libfuse.so.2 > #2 0x0000003452e0f034 in ?? () from /lib64/libfuse.so.2 > #3 0x0000003452a064a7 in start_thread () from /lib64/libpthread.so.0 > #4 0x00000034522d3c2d in clone () from /lib64/libc.so.6 > Thread 1 (Thread 0x2b4f05226420 (LWP 18518)): > #0 0x0000003452a0c9b1 in sem_wait () from /lib64/libpthread.so.0 > #1 0x0000003452e0f235 in fuse_session_loop_mt () from /lib64/libfuse.so.2 > #2 0x0000003452e130b4 in ?? () from /lib64/libfuse.so.2 > #3 0x0000000000402a36 in main () I can't see anything pointing to curl in the stack-trace above. It just hangs on the call of select(), what may fairly possibly signalize a problem in the application logic instead. The backtrace does not show any flaw in curl. Update of curl is not possible on Enterprise Linux. I am closing the bug now. Feel free to reopen once you have a curl-only minimal example. |