From: Jeff King <peff@peff.net>
To: Stefan Beller <stefanbeller@googlemail.com>
Cc: Daniel Stenberg <daniel@haxx.se>, GIT Mailing-list <git@vger.kernel.org>
Subject: Re: error: git-remote-https died of signal 13
Date: Sun, 24 Nov 2013 10:54:39 -0500 [thread overview]
Message-ID: <20131124155439.GA8047@sigill.intra.peff.net> (raw)
In-Reply-To: <529214D7.1030203@googlemail.com>
[+cc Daniel, who worked on the curl fix]
On Sun, Nov 24, 2013 at 04:01:43PM +0100, Stefan Beller wrote:
> On 24.11.2013 14:33, Jeff King wrote:
> > On Sun, Nov 24, 2013 at 01:54:34PM +0100, Stefan Beller wrote:
> >
> >> Here is the output of
> >> sb@sb:/tmp$ GIT_TRANSPORT_HELPER_DEBUG=1 git clone https://github.com/Bertram25/ValyriaTear.git tmp
> >
> > 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
>
> 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
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
---
diff --git a/http.c b/http.c
index bcf54aa..ac709cc 100644
--- a/http.c
+++ b/http.c
@@ -473,13 +473,17 @@ void http_cleanup(void)
{
struct active_request_slot *slot = active_queue_head;
+ warning("in http_cleanup");
while (slot != NULL) {
struct active_request_slot *next = slot->next;
if (slot->curl != NULL) {
#ifdef USE_CURL_MULTI
+ warning("calling curl_multi_remove_handle");
curl_multi_remove_handle(curlm, slot->curl);
#endif
+ warning("calling curl_easy_cleanup on slot");
curl_easy_cleanup(slot->curl);
+ warning("curl_easy_cleanup done");
}
free(slot);
slot = next;
@@ -487,13 +491,19 @@ void http_cleanup(void)
active_queue_head = NULL;
#ifndef NO_CURL_EASY_DUPHANDLE
+ warning("calling curl_easy_cleanup on default");
curl_easy_cleanup(curl_default);
+ warning("curl_easy_cleanup done");
#endif
#ifdef USE_CURL_MULTI
+ warning("calling curl_multi_cleanup");
curl_multi_cleanup(curlm);
+ warning("curl_multi_cleanup done");
#endif
+ warning("calling curl_global_cleanup");
curl_global_cleanup();
+ warning("curl_global_cleanup done");
curl_slist_free_all(pragma_header);
pragma_header = NULL;
next prev parent reply other threads:[~2013-11-24 15:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-23 16:36 error: git-remote-https died of signal 13 Stefan Beller
2013-11-24 6:54 ` Jeff King
2013-11-24 12:54 ` Stefan Beller
2013-11-24 13:33 ` Jeff King
2013-11-24 15:01 ` Stefan Beller
2013-11-24 15:54 ` Jeff King [this message]
2013-11-24 16:13 ` Stefan Beller
2013-11-24 16:32 ` Stefan Beller
2013-11-25 6:39 ` Jeff King
2013-11-25 7:20 ` Daniel Stenberg
2013-11-25 14:32 ` Jeff King
2013-11-25 14:35 ` [curl PATCH 1/2] factor out sigpipe_reset from easy.c Jeff King
2013-11-25 14:43 ` [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup Jeff King
2013-11-27 21:39 ` Daniel Stenberg
2018-05-22 10:26 ` curlUser
2018-05-22 10:50 ` Daniel Stenberg
[not found] ` <CAG4qzjti3MRXZ_Kofbb8b6whwDw7Se8g1VAe0mcU4ZdiWRfxpQ@mail.gmail.com>
2018-05-22 15:06 ` Daniel Stenberg
2018-05-22 15:01 ` curlUser
2018-08-03 12:29 ` dxt29
2013-11-25 14:46 ` error: git-remote-https died of signal 13 Jeff King
2013-11-24 22:13 ` Daniel Stenberg
2013-11-24 23:51 ` brian m. carlson
-- strict thread matches above, loose matches on Subject: below --
2014-04-21 0:42 Greg M
2014-04-23 6:59 ` Jeff King
2014-04-23 11:49 ` Greg M
2014-04-24 4:15 ` Jeff King
2014-04-24 12:11 ` Greg M
2014-04-24 12:15 ` Daniel Stenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131124155439.GA8047@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=daniel@haxx.se \
--cc=git@vger.kernel.org \
--cc=stefanbeller@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).