Bug 595434 - A bug cause curlftpfs hang.
A bug cause curlftpfs hang.
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: curl (Show other bugs)
5.5
All Linux
low Severity medium
: rc
: ---
Assigned To: Kamil Dudka
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-24 11:38 EDT by Kirby Zhou
Modified: 2010-08-05 17:55 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-05 17:55:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kirby Zhou 2010-05-24 11:38:18 EDT
Description of problem:

curlftpfs hangs when it is linked with curl 7.15.5, 7.19.6 is OK.

I had mounted a readonly curlftpfs to do createrepo with remote files for yum, but it hang very often.

Version-Release number of selected component (if applicable):

curl-7.15.5-9.el5

fuse-curlftpfs-0.9.1-1.el5.rf.x86_64.rpm from rpmforge.

I rebuild it with a static linked curl-7.19.6, everything is ok.

Additional info:

http://curlftpfs.sourceforge.net/ says:

22-Jan-2007 - Bad libcurl versions 
A lot of users are reporting problems with CurlFtpFS. We tracked this problems to bugs in libcurl versions 7.15.5 and 7.16.0. Since we depend on 7.15.2 or later and versions 7.15.2 and 7.15.3 have a bug that makes CurlFtpFS do not reuse the connection all the time, the current recommended version of libcurl is either 7.15.4 or the development branch. 


some discussion here:

 curlftpfs hangs when making differential backups using DAR

http://sourceforge.net/tracker/index.php?func=detail&aid=1635141&group_id=160565&atid=816357

 Problem downloading 2 zero byte files with FTP 
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1618359&group_id=976
Comment 1 Kamil Dudka 2010-05-24 12:02:19 EDT
(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?
Comment 2 Kirby Zhou 2010-05-24 12:20:29 EDT
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 ()
Comment 3 Kirby Zhou 2010-05-24 12:27:14 EDT
It is not always hang, 70% chance you hit.
Comment 4 Kamil Dudka 2010-05-24 12:33:31 EDT
(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.
Comment 5 Kamil Dudka 2010-08-05 17:55:07 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.