Description of problem: curl crashes when sftp uploading file into fifo file while scp upload behaves nice might be a libssh2 bug term1# mkfifo /tmp/fifo term1# cksum /tmp/fifo term2# curl -T /tmp/hugefile sftp://localhost/tmp/fifo -u root Enter host password for user 'root': % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed -171 10.0M 0 0 0 -1797 0 -1161 --:--:-- 0:00:15 --:--:-- 0^C file transfer still in progress, printed values doesn't make sense, strace keeps repeating: poll([{fd=4, events=POLLOUT|POLLWRNORM}], 1, 0) = 1 ([{fd=4, revents=POLLOUT|POLLWRNORM}]) recvfrom(4, 0x1460860, 16384, 16384, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) backtrace from Kamil Dudka (probably using fedora versions): # gdb -q --args curl -u root -T /home/libvirt/images/f19.img sftp://localhost/tmp/xxx Reading symbols from /usr/bin/curl...Reading symbols from /usr/lib/debug/usr/bin/curl.debug...done. done. (gdb) run Starting program: /usr/bin/curl -u root -T /home/libvirt/images/f19.img sftp://localhost/tmp/xxx [Thread debugging using libthread_db enabled] Enter host password for user 'root': % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 16.0G 0 0 0 -2290 0 -2543 --:--:-- --:--:-- --:--:-- 0 Program received signal SIGSEGV, Segmentation fault. memcpy () at ../sysdeps/x86_64/memcpy.S:161 161 movzbl (%rsi), %eax Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-13.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 openldap-2.4.23-30.el6.x86_64 openssl-1.0.0-27.el6.x86_64 (gdb) bt #0 memcpy () at ../sysdeps/x86_64/memcpy.S:161 #1 0x00007ffff55601b7 in _libssh2_store_str (buf=0x7fffffffd940, str=0x61bffb <Address 0x61bffb out of bounds>, len=30000) at /usr/include/bits/string3.h:52 #2 0x00007ffff55673d3 in sftp_write (hnd=0x63e160, buffer=0x61bffb <Address 0x61bffb out of bounds>, count=48438) at sftp.c:1864 #3 libssh2_sftp_write (hnd=0x63e160, buffer=0x61bffb <Address 0x61bffb out of bounds>, count=48438) at sftp.c:2004 #4 0x00007ffff7bc56c3 in Curl_sftp_send (conn=0x629db0, sockindex=<value optimized out>, mem=<value optimized out>, len=<value optimized out>) at ssh.c:2781 #5 0x00007ffff7ba1ac8 in Curl_write (conn=0x629db0, sockfd=<value optimized out>, mem=<value optimized out>, len=<value optimized out>, written=0x7fffffffda38) at sendf.c:287 #6 0x00007ffff7bb5307 in readwrite_upload (conn=0x629db0, done=0x7fffffffdade) at transfer.c:1629 #7 Curl_readwrite (conn=0x629db0, done=0x7fffffffdade) at transfer.c:1728 #8 0x00007ffff7bb5e28 in Transfer (data=0x61f570) at transfer.c:1995 #9 Curl_perform (data=0x61f570) at transfer.c:2674 #10 0x0000000000408760 in operate (argc=6460592, argv=<value optimized out>) at main.c:5024 #11 main (argc=6460592, argv=<value optimized out>) at main.c:5339 Version-Release number of selected component (if applicable): curl-7.19.7-26.el6_2.4.x86_64 libssh2-1.2.2-7.el6_2.3.x86_64 How reproducible: always for me Steps to Reproduce: 1. see above Actual results: transfer never finishes (me on 6.3) or curl segfaults (kdudka on Fedora?) Expected results: file uploaded properly
(In reply to comment #0) > transfer never finishes (me on 6.3) or curl segfaults (kdudka on Fedora?) Nope, I had the latest RHEL-6 versions of curl and libssh2. The crash was fixed by the following upstream commit: https://github.com/bagder/curl/commit/1b15b31c However, the patch itself does not make the SFTP upload to FIFO running. This needs to be further investigated...
The above mentioned patch fixes the crash. The fact that curl is not able to upload a file to a remote FIFO using SFTP seems to be limitation of the SFTP server we are using. I am getting the some failure with the sftp(1) client distributed with OpenSSH.
Created attachment 650483 [details] backport of upstream 1b15b31c The second hunk of the patch is not applicable/needed for curl-7.19.7.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0393.html