From: Stefan Beller <hidden> Date: 2016-06-15 22:59:18
Hi,
Using the latest git version (1.8.5.rc3), I get this
this warning/error:
sb@sb:/tmp$ git clone https://github.com/Bertram25/ValyriaTear.git
Cloning into 'ValyriaTear'...
remote: Counting objects: 21346, done.
remote: Compressing objects: 100% (6307/6307), done.
remote: Total 21346 (delta 16463), reused 19820 (delta 15000)
Receiving objects: 100% (21346/21346), 176.39 MiB | 445.00 KiB/s, done.
Resolving deltas: 100% (16463/16463), done.
Checking connectivity... done.
error: git-remote-https died of signal 13
However the repository seems to be cloned fine.
I can clone different repos from github and they are working fine
without the error.
Would that be an issue on my side or on githubs side?
Stefan
From: Jeff King <hidden> Date: 2016-06-15 22:59:18
On Sat, Nov 23, 2013 at 05:36:36PM +0100, Stefan Beller wrote:
sb@sb:/tmp$ git clone https://github.com/Bertram25/ValyriaTear.git
Cloning into 'ValyriaTear'...
remote: Counting objects: 21346, done.
remote: Compressing objects: 100% (6307/6307), done.
remote: Total 21346 (delta 16463), reused 19820 (delta 15000)
Receiving objects: 100% (21346/21346), 176.39 MiB | 445.00 KiB/s, done.
Resolving deltas: 100% (16463/16463), done.
Checking connectivity... done.
error: git-remote-https died of signal 13
However the repository seems to be cloned fine.
I can clone different repos from github and they are working fine
without the error.
Would that be an issue on my side or on githubs side?
Almost certainly on your side. 13 is SIGPIPE, so git-remote-https is
trying to write something but the other side of the pipe has hung up.
This might be a race condition in the transport-helper protocol, where
we've had similar problems before.
It doesn't reproduce here for me. Can you reproduce it consistently on
this repo? I would not be at all surprised if it is intermittent.
If you can reproduce, it would be interesting to see the output with
GIT_TRANSPORT_HELPER_DEBUG=1, or even with "strace -f". That could at
least tell us what it was trying to write (and to where) when it got the
SIGPIPE.
-Peff
From: Stefan Beller <hidden> Date: 2016-06-15 22:59:18
On 24.11.2013 07:54, Jeff King wrote:
On Sat, Nov 23, 2013 at 05:36:36PM +0100, Stefan Beller wrote:
quoted
sb@sb:/tmp$ git clone https://github.com/Bertram25/ValyriaTear.git
Cloning into 'ValyriaTear'...
remote: Counting objects: 21346, done.
remote: Compressing objects: 100% (6307/6307), done.
remote: Total 21346 (delta 16463), reused 19820 (delta 15000)
Receiving objects: 100% (21346/21346), 176.39 MiB | 445.00 KiB/s, done.
Resolving deltas: 100% (16463/16463), done.
Checking connectivity... done.
error: git-remote-https died of signal 13
However the repository seems to be cloned fine.
I can clone different repos from github and they are working fine
without the error.
Would that be an issue on my side or on githubs side?
Almost certainly on your side. 13 is SIGPIPE, so git-remote-https is
trying to write something but the other side of the pipe has hung up.
This might be a race condition in the transport-helper protocol, where
we've had similar problems before.
It doesn't reproduce here for me. Can you reproduce it consistently on
this repo? I would not be at all surprised if it is intermittent.
I tested 3 times before sending the mail and I always got the error.
Testing now doesn't always trigger this problem. So yeah it's kind of intermittent.
If you can reproduce, it would be interesting to see the output with
GIT_TRANSPORT_HELPER_DEBUG=1, or even with "strace -f". That could at
least tell us what it was trying to write (and to where) when it got the
SIGPIPE.
-Peff
Thanks. I think I see what is going on.
We finish the helper conversation here:
Checking connectivity... done.
Debug: Disconnecting.
error: git-remote-https died of signal 13
sb@sb:/tmp$
which means that remote-https is trying to exit, and is cleaning up any
curl connections. The actual SIGPIPE in the strace is here:
[pid 28319] write(3, "\25\3\2\0...[binary goo]...", 27) = -1 EPIPE (Broken pipe)
and if you walk backwards, fd 3 is:
[pid 28319] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
...
[pid 28319] connect(3, {sa_family=AF_INET,
sin_port=htons(443),
sin_addr=inet_addr("192.30.252.131")}, 16
) = -1 EINPROGRESS (Operation now in progress)
So it's sending binary junk to the https socket while trying to exit,
which makes me guess that it's something to do with terminating the SSL
session, but the server has already hung up. Which would make it a curl
problem.
Googling "curl sigpipe" seems to come up with a report of this exact
case:
http://curl.haxx.se/mail/archive-2013-01/0003.html
with a bug opened here:
http://sourceforge.net/p/curl/bugs/1180/
Looks like the fix went into curl 7.32.0. I have 7.33.0, which seems
fine. Can you confirm that your libcurl is a bit older?
-Peff
Thanks. I think I see what is going on.
We finish the helper conversation here:
quoted
Checking connectivity... done.
Debug: Disconnecting.
error: git-remote-https died of signal 13
sb@sb:/tmp$
which means that remote-https is trying to exit, and is cleaning up any
curl connections. The actual SIGPIPE in the strace is here:
[pid 28319] write(3, "\25\3\2\0...[binary goo]...", 27) = -1 EPIPE (Broken pipe)
and if you walk backwards, fd 3 is:
[pid 28319] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
...
[pid 28319] connect(3, {sa_family=AF_INET,
sin_port=htons(443),
sin_addr=inet_addr("192.30.252.131")}, 16
) = -1 EINPROGRESS (Operation now in progress)
So it's sending binary junk to the https socket while trying to exit,
which makes me guess that it's something to do with terminating the SSL
session, but the server has already hung up. Which would make it a curl
problem.
Googling "curl sigpipe" seems to come up with a report of this exact
case:
http://curl.haxx.se/mail/archive-2013-01/0003.html
I cannot reproduce the error using the curl command from that site.
curl returns with 0.
with a bug opened here:
http://sourceforge.net/p/curl/bugs/1180/
Looks like the fix went into curl 7.32.0. I have 7.33.0, which seems
fine. Can you confirm that your libcurl is a bit older?
dpkg -l |grep curl
ii curl 7.32.0-1ubuntu1 amd64 command line tool for transferring data with URL syntax
ii libcurl3:amd64 7.32.0-1ubuntu1 amd64 easy-to-use client-side URL transfer library (OpenSSL flavour)
ii libcurl3-gnutls:amd64 7.32.0-1ubuntu1 amd64 easy-to-use client-side URL transfer library (GnuTLS flavour)
ii libcurl4-openssl-dev 7.32.0-1ubuntu1 amd64 development files and documentation for libcurl (OpenSSL flavour)
ii python-pycurl 7.19.0-5ubuntu8 amd64 Python bindings to libcurl
Thanks,
Stefan
Thanks. I think I see what is going on.
We finish the helper conversation here:
quoted
Checking connectivity... done.
Debug: Disconnecting.
error: git-remote-https died of signal 13
sb@sb:/tmp$
which means that remote-https is trying to exit, and is cleaning up any
curl connections. The actual SIGPIPE in the strace is here:
[pid 28319] write(3, "\25\3\2\0...[binary goo]...", 27) = -1 EPIPE (Broken pipe)
and if you walk backwards, fd 3 is:
[pid 28319] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
...
[pid 28319] connect(3, {sa_family=AF_INET,
sin_port=htons(443),
sin_addr=inet_addr("192.30.252.131")}, 16
) = -1 EINPROGRESS (Operation now in progress)
So it's sending binary junk to the https socket while trying to exit,
which makes me guess that it's something to do with terminating the SSL
session, but the server has already hung up. Which would make it a curl
problem.
Googling "curl sigpipe" seems to come up with a report of this exact
case:
http://curl.haxx.se/mail/archive-2013-01/0003.html
I cannot reproduce the error using the curl command from that site.
curl returns with 0.
quoted
with a bug opened here:
http://sourceforge.net/p/curl/bugs/1180/
Looks like the fix went into curl 7.32.0. I have 7.33.0, which seems
fine. Can you confirm that your libcurl is a bit older?
dpkg -l |grep curl
ii curl 7.32.0-1ubuntu1 amd64 command line tool for transferring data with URL syntax
ii libcurl3:amd64 7.32.0-1ubuntu1 amd64 easy-to-use client-side URL transfer library (OpenSSL flavour)
ii libcurl3-gnutls:amd64 7.32.0-1ubuntu1 amd64 easy-to-use client-side URL transfer library (GnuTLS flavour)
ii libcurl4-openssl-dev 7.32.0-1ubuntu1 amd64 development files and documentation for libcurl (OpenSSL flavour)
ii python-pycurl 7.19.0-5ubuntu8 amd64 Python bindings to libcurl
Hmm. The fix in curl's 7d80ed64e435155 seems to involve strategically
placed calls to ignore SIGPIPE. I wonder if there is another spot that
needs similar treatment. It looks like curl_easy_cleanup is covered,
though, and that's where I would expect problem to come.
It would be interesting to see a backtrace from remote-curl when we get
the SIGPIPE. Doing so would be slightly tricky; instrumenting with the
patch below may be enough.
Another thought is that the curl fix seems to only kick in when built
with openssl support. I'm not sure I understand how ubuntu's packaging
of curl uses gnutls versus openssl for the shared library. That may be
related.
-Peff
---
From: Stefan Beller <hidden> Date: 2016-06-15 22:59:19
On 24.11.2013 16:54, Jeff King wrote:
Hmm. The fix in curl's 7d80ed64e435155 seems to involve strategically
placed calls to ignore SIGPIPE. I wonder if there is another spot that
needs similar treatment. It looks like curl_easy_cleanup is covered,
though, and that's where I would expect problem to come.
It would be interesting to see a backtrace from remote-curl when we get
the SIGPIPE. Doing so would be slightly tricky; instrumenting with the
patch below may be enough.
Ok I'll test that now.
Another thought is that the curl fix seems to only kick in when built
with openssl support. I'm not sure I understand how ubuntu's packaging
of curl uses gnutls versus openssl for the shared library. That may be
related.
A better information would be the --version from curl then:
curl --version
curl 7.32.0 (x86_64-pc-linux-gnu) libcurl/7.32.0 OpenSSL/1.0.1e zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
Thanks. I think I see what is going on.
We finish the helper conversation here:
quoted
Checking connectivity... done.
Debug: Disconnecting.
error: git-remote-https died of signal 13
sb@sb:/tmp$
which means that remote-https is trying to exit, and is cleaning up any
curl connections. The actual SIGPIPE in the strace is here:
[pid 28319] write(3, "\25\3\2\0...[binary goo]...", 27) = -1 EPIPE (Broken pipe)
and if you walk backwards, fd 3 is:
[pid 28319] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
...
[pid 28319] connect(3, {sa_family=AF_INET,
sin_port=htons(443),
sin_addr=inet_addr("192.30.252.131")}, 16
) = -1 EINPROGRESS (Operation now in progress)
So it's sending binary junk to the https socket while trying to exit,
which makes me guess that it's something to do with terminating the SSL
session, but the server has already hung up. Which would make it a curl
problem.
Googling "curl sigpipe" seems to come up with a report of this exact
case:
http://curl.haxx.se/mail/archive-2013-01/0003.html
I cannot reproduce the error using the curl command from that site.
curl returns with 0.
quoted
with a bug opened here:
http://sourceforge.net/p/curl/bugs/1180/
Looks like the fix went into curl 7.32.0. I have 7.33.0, which seems
fine. Can you confirm that your libcurl is a bit older?
dpkg -l |grep curl
ii curl 7.32.0-1ubuntu1 amd64 command line tool for transferring data with URL syntax
ii libcurl3:amd64 7.32.0-1ubuntu1 amd64 easy-to-use client-side URL transfer library (OpenSSL flavour)
ii libcurl3-gnutls:amd64 7.32.0-1ubuntu1 amd64 easy-to-use client-side URL transfer library (GnuTLS flavour)
ii libcurl4-openssl-dev 7.32.0-1ubuntu1 amd64 development files and documentation for libcurl (OpenSSL flavour)
ii python-pycurl 7.19.0-5ubuntu8 amd64 Python bindings to libcurl
Hmm. The fix in curl's 7d80ed64e435155 seems to involve strategically
placed calls to ignore SIGPIPE. I wonder if there is another spot that
needs similar treatment. It looks like curl_easy_cleanup is covered,
though, and that's where I would expect problem to come.
It would be interesting to see a backtrace from remote-curl when we get
the SIGPIPE. Doing so would be slightly tricky; instrumenting with the
patch below may be enough.
From: Daniel Stenberg <hidden> Date: 2016-06-15 22:59:19
On Sun, 24 Nov 2013, Jeff King wrote:
Hmm. The fix in curl's 7d80ed64e435155 seems to involve strategically placed
calls to ignore SIGPIPE. I wonder if there is another spot that needs
similar treatment. It looks like curl_easy_cleanup is covered, though, and
that's where I would expect problem to come.
Sounds like a plausible reason.
It would be interesting to see a backtrace from remote-curl when we get the
SIGPIPE. Doing so would be slightly tricky; instrumenting with the patch
below may be enough.
Another thought is that the curl fix seems to only kick in when built with
openssl support. I'm not sure I understand how ubuntu's packaging of curl
uses gnutls versus openssl for the shared library. That may be related.
I'm only aware of a SIGPIPE problem with openssl that can make it write to the
socket in some situations when the remote end is no longer there - something
we can't prevent it from doing.
I *believe* the problem doesn't exist in the similar way when built to use
gnutls, but I may of course be wrong.
--
/ daniel.haxx.se
From: brian m. carlson <hidden> Date: 2016-06-15 22:59:19
On Sun, Nov 24, 2013 at 10:54:39AM -0500, Jeff King wrote:
Another thought is that the curl fix seems to only kick in when built
with openssl support. I'm not sure I understand how ubuntu's packaging
of curl uses gnutls versus openssl for the shared library. That may be
related.
Debian (and presumably Ubuntu) build the curl source three times: once
each for OpenSSL, GnuTLS, and NSS. Each shared library is named
differently (libcurl-openssl.so.3, etc.) and in its own package
(libcurl3-openssl). The corresponding -dev package for each version
sets up the symlinks and install headers to point to the proper version,
so you always compile and link as you expect.
The reason for this is that Debian cannot distribute GPLv2-only programs
(like git) linked against OpenSSL, so GnuTLS becomes necessary. On
Debian and Ubuntu, git is by default linked against libcurl3-gnutls.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Thanks. I'm having trouble reproducing the SIGPIPE locally, but I am
able to see via strace the write we make in curl_multi_cleanup. The
call stack is:
curl_multi_cleanup
-> close_all_connections
-> Curl_disconnect
-> Curl_ossl_close
...
Daniel, does the call to Curl_disconnect need to be wrapped with
sigpipe_ignore/reset, similar to 7d80ed64e435155?
-Peff
From: Daniel Stenberg <hidden> Date: 2016-06-15 22:59:19
On Mon, 25 Nov 2013, Jeff King wrote:
Thanks. I'm having trouble reproducing the SIGPIPE locally, but I am able to
see via strace the write we make in curl_multi_cleanup. The call stack is:
curl_multi_cleanup
-> close_all_connections
-> Curl_disconnect
-> Curl_ossl_close
...
Daniel, does the call to Curl_disconnect need to be wrapped with
sigpipe_ignore/reset, similar to 7d80ed64e435155?
Yes. It very much looks like that. The SSL "closing" is what was the problem I
had to adress.
But I then decided that if a 3rd library has one way to generate SIGPIPE it
may very well have another in a separate spot so I decided to do the wrap at
the top level immediately in the entry point when getting called by the
application. Following that, the SIGPIPE ignore/restore should rather be made
in curl_multi_cleanup.
--
/ daniel.haxx.se
From: Jeff King <hidden> Date: 2016-06-15 22:59:19
On Mon, Nov 25, 2013 at 08:20:18AM +0100, Daniel Stenberg wrote:
quoted
Daniel, does the call to Curl_disconnect need to be wrapped with
sigpipe_ignore/reset, similar to 7d80ed64e435155?
Yes. It very much looks like that. The SSL "closing" is what was the
problem I had to adress.
But I then decided that if a 3rd library has one way to generate
SIGPIPE it may very well have another in a separate spot so I decided
to do the wrap at the top level immediately in the entry point when
getting called by the application. Following that, the SIGPIPE
ignore/restore should rather be made in curl_multi_cleanup.
Unfortunately, we need an actual SessionHandle to know whether it is OK
to reset signals at all. There may be a more elegant way of checking
that, but here's the patch series I came up with. It does turn off
SIGPIPE for the specific case I'm seeing (again, I'm having trouble
actually getting EPIPE in the first place, but from Stefan's strace, I
think this would fix his problem).
[1/2]: factor out sigpipe_reset from easy.c
[2/2]: ignore SIGPIPE during curl_multi_cleanup
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:59:19
Commit 7d80ed64e43515 introduced some helpers to handle
sigpipe in easy.c. However, that fix was incomplete, and we
need to add more callers in other files. The first step is
making the helpers globally accessible.
Since the functions are small and should generally end up
inlined anyway, we simply define them in the header as
static functions.
Signed-off-by: Jeff King <redacted>
---
We can also do it as a separate '.c' file if you prefer.
Note that this will #include the system signal.h at a different point in
easy.c now (in particular, after we have included more local headers). I
don't know if that has any portability implications.
I almost wonder if the SIGPIPE_IGNORE definition (and inclusion of
signal.h) should go into curl-setup.h. I have very little knowledge of
the curl code base and conventions, so please feel free to hack it up or
point me in the right direction.
lib/Makefile.inc | 2 +-
lib/easy.c | 56 +-----------------------------------------------------
lib/sigpipe.h | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 60 insertions(+), 56 deletions(-)
create mode 100644 lib/sigpipe.h
@@ -78,6 +73,7 @@#include"warnless.h"#include"conncache.h"#include"multiif.h"+#include"sigpipe.h"#define _MPRINTF_REPLACE /* use our functions only */#include<curl/mprintf.h>
@@ -85,56 +81,6 @@/* The last #include file should be: */#include"memdebug.h"-#ifdef SIGPIPE_IGNORE-structsigpipe_ignore{-structsigactionold_pipe_act;-boolno_signal;-};--#define SIGPIPE_VARIABLE(x) struct sigpipe_ignore x--/*-*sigpipe_ignore()makessureweignoreSIGPIPEwhilerunninglibcurl-*internals,andthensigpipe_restore()willrestorethesituationwhenwe-*returnfromlibcurlagain.-*/-staticvoidsigpipe_ignore(structSessionHandle*data,-structsigpipe_ignore*ig)-{-/* get a local copy of no_signal because the SessionHandle might not be-aroundwhenwerestore*/-ig->no_signal=data->set.no_signal;-if(!data->set.no_signal){-structsigactionaction;-/* first, extract the existing situation */-memset(&ig->old_pipe_act,0,sizeof(structsigaction));-sigaction(SIGPIPE,NULL,&ig->old_pipe_act);-action=ig->old_pipe_act;-/* ignore this signal */-action.sa_handler=SIG_IGN;-sigaction(SIGPIPE,&action,NULL);-}-}--/*-*sigpipe_restore()putsbacktheoutsideworld'sopinionofsignalhandler-*andSIGPIPEhandling.ItMUSTonlybecalledafteracorresponding-*sigpipe_ignore()wasused.-*/-staticvoidsigpipe_restore(structsigpipe_ignore*ig)-{-if(!ig->no_signal)-/* restore the outside state */-sigaction(SIGPIPE,&ig->old_pipe_act,NULL);-}--#else-/* for systems without sigaction */-#define sigpipe_ignore(x,y) Curl_nop_stmt-#define sigpipe_restore(x) Curl_nop_stmt-#define SIGPIPE_VARIABLE(x)-#endif-/* win32_cleanup() is for win32 socket cleanup functionality, the oppositeofwin32_init()*/staticvoidwin32_cleanup(void)
@@ -0,0 +1,58 @@+#ifndef HEADER_CURL_SIGPIPE_H+#define HEADER_CURL_SIGPIPE_H++#include"curl_setup.h"++#if defined(HAVE_SIGNAL_H) && defined(HAVE_SIGACTION) && defined(USE_OPENSSL)+#include<signal.h>++structsigpipe_ignore{+structsigactionold_pipe_act;+boolno_signal;+};++#define SIGPIPE_VARIABLE(x) struct sigpipe_ignore x++/*+*sigpipe_ignore()makessureweignoreSIGPIPEwhilerunninglibcurl+*internals,andthensigpipe_restore()willrestorethesituationwhenwe+*returnfromlibcurlagain.+*/+staticvoidsigpipe_ignore(structSessionHandle*data,+structsigpipe_ignore*ig)+{+/* get a local copy of no_signal because the SessionHandle might not be+aroundwhenwerestore*/+ig->no_signal=data->set.no_signal;+if(!data->set.no_signal){+structsigactionaction;+/* first, extract the existing situation */+memset(&ig->old_pipe_act,0,sizeof(structsigaction));+sigaction(SIGPIPE,NULL,&ig->old_pipe_act);+action=ig->old_pipe_act;+/* ignore this signal */+action.sa_handler=SIG_IGN;+sigaction(SIGPIPE,&action,NULL);+}+}++/*+*sigpipe_restore()putsbacktheoutsideworld'sopinionofsignalhandler+*andSIGPIPEhandling.ItMUSTonlybecalledafteracorresponding+*sigpipe_ignore()wasused.+*/+staticvoidsigpipe_restore(structsigpipe_ignore*ig)+{+if(!ig->no_signal)+/* restore the outside state */+sigaction(SIGPIPE,&ig->old_pipe_act,NULL);+}++#else+/* for systems without sigaction */+#define sigpipe_ignore(x,y) Curl_nop_stmt+#define sigpipe_restore(x) Curl_nop_stmt+#define SIGPIPE_VARIABLE(x)+#endif++#endif /* HEADER_CURL_SIGPIPE_H */
From: Jeff King <hidden> Date: 2016-06-15 22:59:19
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.
Signed-off-by: Jeff King <redacted>
---
I really am just cargo-culting here. I have no idea what
multi->closure_handle does, except that it gets used as conn->data for
the connection we pass to Curl_disconnect, so it seems like a reasonable
place to check for the magic no_signal variable.
lib/multi.c | 9 +++++++++
1 file changed, 9 insertions(+)
@@ -41,6 +41,7 @@#include"bundles.h"#include"multihandle.h"#include"pipeline.h"+#include"sigpipe.h"#define _MPRINTF_REPLACE /* use our functions only */#include<curl/mprintf.h>
@@ -1786,12 +1787,18 @@ CURLMcode curl_multi_cleanup(CURLM *multi_handle)structSessionHandle*nextdata;if(GOOD_MULTI_HANDLE(multi)){+SIGPIPE_VARIABLE(pipe);+boolrestore_pipe=FALSE;+multi->type=0;/* not good anymore *//* Close all the connections in the connection cache */close_all_connections(multi);if(multi->closure_handle){+sigpipe_ignore(multi->closure_handle,&pipe);+restore_pipe=TRUE;+multi->closure_handle->dns.hostcache=multi->hostcache;Curl_hostcache_clean(multi->closure_handle,multi->closure_handle->dns.hostcache);
From: Jeff King <hidden> Date: 2016-06-15 22:59:19
On Mon, Nov 25, 2013 at 09:32:13AM -0500, Jeff King wrote:
quoted
But I then decided that if a 3rd library has one way to generate
SIGPIPE it may very well have another in a separate spot so I decided
to do the wrap at the top level immediately in the entry point when
getting called by the application. Following that, the SIGPIPE
ignore/restore should rather be made in curl_multi_cleanup.
Unfortunately, we need an actual SessionHandle to know whether it is OK
to reset signals at all. There may be a more elegant way of checking
that, but here's the patch series I came up with.
Scratch that. I had originally written something like:
if (conn->data)
sigpipe_ignore(conn->data, &pipe);
Curl_disconnect(conn, ...);
sigpipe_restore(&pipe);
but while sending it out, I realized that the "data" we attach to each
connection when we close it is just the multi->closure_handle. So I was
able to hoist the check out to curl_multi_cleanup (and that's what I
just sent).
-Peff
From: Daniel Stenberg <hidden> Date: 2016-06-15 22:59:20
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
Hi,
Again SIGPIPE is seen with curl version 7.45.0 with multi interface.
Backtrace shows :
#7 0x00007f141bea40cd in Curl_ossl_close (conn=0x7f14193f9848, sockindex=0)
at vtls/openssl.c:881
#8 0x00007f141bea8f54 in Curl_ssl_close (conn=0x7f14193f9848, sockindex=0)
at vtls/vtls.c:527
#9 0x00007f141be63969 in Curl_disconnect (conn=0x7f14193f9848,
dead_connection=true) at url.c:2791
#10 0x00007f141be63f4b in disconnect_if_dead (conn=0x7f14193f9848,
data=0xb6a598) at url.c:3050
#11 0x00007f141be63f84 in call_disconnect_if_dead (conn=0x7f14193f9848,
param=0xb6a598) at url.c:3066
#12 0x00007f141bea01c2 in Curl_conncache_foreach (connc=0xae0f48,
param=0xb6a598, func=0x7f141be63f59 <call_disconnect_if_dead>)
at conncache.c:295
#13 0x00007f141be6400f 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/
From: Daniel Stenberg <hidden> Date: 2018-05-22 10:50:07
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
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/
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/