git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: error: git-remote-https died of signal 13

From
Stefan Beller <stefanbeller@googlemail.com>
Date
Nov 24, 2013, 16:32 UTC
Message-ID
<52922A22.2090109@googlemail.com>
In-Reply-To
<20131124155439.GA8047@sigill.intra.peff.net>
On 24.11.2013 16:54, Jeff King wrote:
Show 71 quoted lines
> [+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

Previous: Stefan BellerNext: Jeff King
Message 8 of 22 in “error: git-remote-https died of signal 13”
  1. Stefan BellerNov 23, 2013
  2. Jeff KingNov 24, 2013
  3. Stefan BellerNov 24, 2013
  4. Jeff KingNov 24, 2013
  5. Stefan BellerNov 24, 2013
  6. Jeff KingNov 24, 2013
  7. Stefan BellerNov 24, 2013
  8. Stefan BellerNov 24, 2013
  9. Jeff KingNov 25, 2013
  10. Daniel StenbergNov 25, 2013
  11. Jeff KingNov 25, 2013
  12. 1/2 factor out sigpipe_reset from easy.cJeff King, Nov 25, 2013
  13. 2/2 ignore SIGPIPE during curl_multi_cleanupJeff King, Nov 25, 2013
  14. Daniel StenbergNov 27, 2013
  15. curlUserMay 22, 2018
  16. Daniel StenbergMay 22, 2018
  17. curlUserMay 22, 2018
  18. dxt29Aug 3, 2018
  19. Jeff KingNov 25, 2013
  20. Daniel StenbergNov 24, 2013
  21. brian m. carlsonNov 24, 2013
  22. Daniel StenbergMay 22, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.