git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <stefanbeller@googlemail.com>
To: Jeff King <peff@peff.net>
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 17:32:34 +0100	[thread overview]
Message-ID: <52922A22.2090109@googlemail.com> (raw)
In-Reply-To: <20131124155439.GA8047@sigill.intra.peff.net>

On 24.11.2013 16:54, Jeff King wrote:
> [+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.
> 

GIT_TRANSPORT_HELPER_DEBUG=1 git clone https://github.com/Bertram25/ValyriaTear.git
now ends with:

Debug: Remote helper: Waiting...
remote: Counting objects: 21354, done.
remote: Compressing objects: 100% (6249/6249), done.
remote: Total 21354 (delta 16466), reused 19888 (delta 15066)
Receiving objects: 100% (21354/21354), 176.42 MiB | 1.22 MiB/s, done.
Resolving deltas: 100% (16466/16466), done.
Debug: Remote helper: <- lock /tmp/ValyriaTear/.git/objects/pack/pack-b6f360ab28b5078a9aefafe1c4144e6c7782c317.keep
Debug: Remote helper: Waiting...
Debug: Remote helper: <- connectivity-ok
Debug: Remote helper: Waiting...
Debug: Remote helper: <- 
Checking connectivity... done.
Debug: Disconnecting.
warning: in http_cleanup
warning: calling curl_multi_remove_handle
warning: calling curl_easy_cleanup on slot
warning: curl_easy_cleanup done
warning: calling curl_easy_cleanup on default
warning: curl_easy_cleanup done
warning: calling curl_multi_cleanup
error: git-remote-https died of signal 13

Thanks,
Stefan

  parent reply	other threads:[~2013-11-24 16:32 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
2013-11-24 16:13           ` Stefan Beller
2013-11-24 16:32           ` Stefan Beller [this message]
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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52922A22.2090109@googlemail.com \
    --to=stefanbeller@googlemail.com \
    --cc=daniel@haxx.se \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).