Bug 813127

(In reply to comment #0)
>   The problem appears to be related to this debian bug report (contains dialog
> with upstream maintainers of libcurl):
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572276

This is said to be the upstream fix for the issue:

    https://github.com/bagder/curl/commit/7fd32ce

Could you please check whether the fix solves your problem?

Created attachment 578004 [details]
backport of upstream commit 7fd32ce

> This is said to be the upstream fix for the issue:
> 
>     https://github.com/bagder/curl/commit/7fd32ce
> 
> Could you please check whether the fix solves your problem?


Have cloned the upstream github, checked-out the 7fd32ce version, built and installed that version.

So far I've been unable to reproduce the problem using that specific version.


My testing involves an infinite loop that breaks when curl returns error 18.
This test has been running continuously for over an hour without problem.

while : ; do /usr/local/bin/curl -v http://192.168.1.1:8181/yum/rhel/6.2/i386/repodata/repomd.xml ; case $? in 0) continue ;; *) break ;; esac ; done

Using the system curl 7.19-7 located in /usr/bin/curl we are able to reproduce the problem using the same method very quickly.

I feel safe in saying that this solves the problem.

Hopefully we can get this back-ported.

Thank you.

Thanks for the testing, but you tested curl-7_20_1~75, which has not much in common with the version we have in RHEL-6.  Could you please test it with libcurl-7.19.7-26.el6_2.4 with the attached patch applied?  I can prepare an SRPM for testing purposes if needed.

Sorry about that, I mistakenly thought you wanted the specific upstream version tested.


I installed the src.rpm curl-7.19.7-26.el6_2.4, created the patch, fixed up the spec file, and built the program. 

Unfortunately that did not solve the problem as my test case still fails using the new binary.

Here is some info about what was built:

# /root/rpmbuild/BUILDROOT/curl-7.19.7-26.el6.4.i386/usr/bin/curl -V
curl 7.19.7 (i686-pc-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

The above features your attached patch on this bz.



Here is my test:

while /root/rpmbuild/BUILDROOT/curl-7.19.7-26.el6.4.i386/usr/bin/curl http://192.168.1.1:8181/yum/rhel/6.2/i386/repodata/repomd.xml > /dev/null ;
 do continue ;
done

[... about 4 or 5 loop cycles] 

curl: (18) transfer closed with outstanding read data remaining




What kills me is that I built another binary from the same curl-7.19.7-26.el6_2.4.src.rpm that does work every single time, and the above loop repeats forever. I just installed that src.rpm, ran buildconf, configure, and make install. The resulting binary in /usr/local/bin/curl doesn't support many features but it works. Please note this binary works with the transfer.c manually patched or left intact. 







# /usr/local/bin/curl -V
curl 7.19.7 (i686-pc-linux-gnu) libcurl/7.20.1-DEV
Protocols: dict file ftp http imap pop3 rtsp smtp telnet tftp
Features: IPv6 Largefile



To make it even more confusing, when I start to use ftrace in my testing then for some reason curl never fails.

(In reply to comment #6)
> Here is my test:
> 
> while /root/rpmbuild/BUILDROOT/curl-7.19.7-26.el6.4.i386/usr/bin/curl
> http://192.168.1.1:8181/yum/rhel/6.2/i386/repodata/repomd.xml > /dev/null ;
>  do continue ;
> done

This ^^^ is not sufficient for the patch to take an effect.  You are most likely running a new version of the tool (which does not really differ from the old one) against the old version of the library installed on your system.  Please run this command prior to your testing:

> export LD_PRELOAD=$(find /root/rpmbuild/BUILDROOT/curl-7.19.7-26.el6.4.i386 -name libcurl.so)

... and double-check that the patched library is being loaded:

> ldd /root/rpmbuild/BUILDROOT/curl-7.19.7-26.el6.4.i386/usr/bin/curl

After using LD_PRELOAD the test ran without fail.


Thank you.

Great, thanks for testing it!

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