Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

2018-08-03 Thread dxt29
I have curl 7.35.0 installed on my ubuntu14.04, version infos is as below


I have recompiled git against openssl. the git version is 1.9.1. I
encountered this error "error: git-remote-http died of signal 13" when I
issue `git clone http://github.com/tensorflow/tensorflow.git`. Should I
upgrade curl to a higher version? Or is there other easy solutions?

Thanks.



--
Sent from: http://git.661346.n2.nabble.com/


Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

2018-05-22 Thread Daniel Stenberg

On Tue, 22 May 2018, Suganthi wrote:

We may not be able to upgrade to 7.60.0 any soon, Is the fix present in 7.45 
, in this sequence of code. Please let me know.


I don't know.

I can't recall any SIGPIPE problems in recent days in libcurl, which is why I 
believe this problem doesn't exist anymore. libcurl 7.45.0 is 2.5 years and 
1500+ bug fixes old after all. My casual searches for a curl problem like this 
- fixed in 7.45.0 or later - also failed.


--

 / daniel.haxx.se


Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

2018-05-22 Thread curlUser
We may not be able to upgrade to 7.60.0 any soon, 
Is the fix present in 7.45 , in this sequence of code. 
Please let me know. 



--
Sent from: http://git.661346.n2.nabble.com/


Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

2018-05-22 Thread Daniel Stenberg

On Tue, 22 May 2018, curlUser wrote:


Again SIGPIPE is seen with curl version 7.45.0 with multi interface.
Backtrace shows :


...

Looks like SIGPIPE_IGNORE to be added in prune_dead connections or in 
disconnect_if_dead? Can anyone comment on this.


I'm pretty sure this issue isn't present in any recent libcurl versions, but 
if you can reproduce it with 7.60.0, I'll be very interested.


--

 / daniel.haxx.se


Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

2018-05-22 Thread curlUser
Hi,

Again SIGPIPE is seen with curl version 7.45.0 with multi interface.
Backtrace shows :

#7  0x7f141bea40cd in Curl_ossl_close (conn=0x7f14193f9848, sockindex=0)
at vtls/openssl.c:881
#8  0x7f141bea8f54 in Curl_ssl_close (conn=0x7f14193f9848, sockindex=0)
at vtls/vtls.c:527
#9  0x7f141be63969 in Curl_disconnect (conn=0x7f14193f9848,
dead_connection=true) at url.c:2791
#10 0x7f141be63f4b in disconnect_if_dead (conn=0x7f14193f9848,
data=0xb6a598) at url.c:3050
#11 0x7f141be63f84 in call_disconnect_if_dead (conn=0x7f14193f9848,
param=0xb6a598) at url.c:3066
#12 0x7f141bea01c2 in Curl_conncache_foreach (connc=0xae0f48,
param=0xb6a598, func=0x7f141be63f59 )
at conncache.c:295
#13 0x7f141be6400f in prune_dead_connections (data=0xb6a598) at
url.c:3081

Looks like SIGPIPE_IGNORE to be added in prune_dead connections or in
disconnect_if_dead?
Can anyone comment on this. 



--
Sent from: http://git.661346.n2.nabble.com/


Re: curl

2015-04-28 Thread Carlos Martín Nieto
On Tue, 2015-04-28 at 00:57 -0400, Jeff King wrote:
 On Mon, Apr 27, 2015 at 11:49:51PM -0300, Thiago Farina wrote:
 
  Is it right that git uses libcurl to download while libgit2 does without it?
 
 I'm not sure if you mean right as in this statement is true or as in
 is this a good thing that it is the case.
 
 For the former, yes, libgit2 does not use curl.  On Windows, it can use
 the native http calls (which do nice things like using the system proxy
 and auth systems). On Unix, I think it is a combination of hand-rolled
 code, openssl, and an imported http parser (from nginx).
 
 Whether that is a good idea or not, I can't comment too much. From what
 I have seen discussed in libgit2 issues, the stock http transport is
 meant to be bare-bones (but with minimal dependencies). But it could
 co-exist with a curl transport (just as it does with the WinHTTP
 transport).  Maybe Carlos (cc'd) can say more.

This is accurate, though I'll add that the development version of
libgit2 now uses SecureTransport instead of OpenSSL on Mac OS X.

But this is just the default. You can replace what libgit2 will use as a
transport if you have special needs. Visual Studio use their own network
code, and the cargo package manager uses libcurl. Eventually libcurl
support will likely be added to mainline libgit2, when we find time.

   cmn


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: curl

2015-04-27 Thread Jeff King
On Mon, Apr 27, 2015 at 11:49:51PM -0300, Thiago Farina wrote:

 Is it right that git uses libcurl to download while libgit2 does without it?

I'm not sure if you mean right as in this statement is true or as in
is this a good thing that it is the case.

For the former, yes, libgit2 does not use curl.  On Windows, it can use
the native http calls (which do nice things like using the system proxy
and auth systems). On Unix, I think it is a combination of hand-rolled
code, openssl, and an imported http parser (from nginx).

Whether that is a good idea or not, I can't comment too much. From what
I have seen discussed in libgit2 issues, the stock http transport is
meant to be bare-bones (but with minimal dependencies). But it could
co-exist with a curl transport (just as it does with the WinHTTP
transport).  Maybe Carlos (cc'd) can say more.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

2013-11-27 Thread Daniel Stenberg

On Mon, 25 Nov 2013, Jeff King wrote:

This is an extension to the fix in 7d80ed64e43515. We may call 
Curl_disconnect() while cleaning up the multi handle, which could lead to 
openssl sending packets, which could get a SIGPIPE.


Thanks a lot. I'll merge these ones in a second and they will be included in 
the coming 7.34.0 release (due to ship in mid December).


--

 / daniel.haxx.se
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html