From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: error: git-remote-https died of signal 13 Date: Mon, 25 Nov 2013 09:32:13 -0500 Message-ID: <20131125143213.GA22642@sigill.intra.peff.net> References: <5290D994.9040505@googlemail.com> <20131124065400.GB5535@sigill.intra.peff.net> <5291F70A.7070508@googlemail.com> <20131124133356.GA3507@sigill.intra.peff.net> <529214D7.1030203@googlemail.com> <20131124155439.GA8047@sigill.intra.peff.net> <52922A22.2090109@googlemail.com> <20131125063945.GA16313@sigill.intra.peff.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Stefan Beller , GIT Mailing-list To: Daniel Stenberg X-From: git-owner@vger.kernel.org Mon Nov 25 15:32:25 2013 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VkxD6-0004KF-Lu for gcvg-git-2@plane.gmane.org; Mon, 25 Nov 2013 15:32:25 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932171Ab3KYOcT (ORCPT ); Mon, 25 Nov 2013 09:32:19 -0500 Received: from cloud.peff.net ([50.56.180.127]:45315 "HELO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1757806Ab3KYOcR (ORCPT ); Mon, 25 Nov 2013 09:32:17 -0500 Received: (qmail 10728 invoked by uid 102); 25 Nov 2013 14:32:17 -0000 Received: from c-71-63-4-13.hsd1.va.comcast.net (HELO sigill.intra.peff.net) (71.63.4.13) (smtp-auth username relayok, mechanism cram-md5) by peff.net (qpsmtpd/0.84) with ESMTPA; Mon, 25 Nov 2013 08:32:17 -0600 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Mon, 25 Nov 2013 09:32:13 -0500 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Mon, Nov 25, 2013 at 08:20:18AM +0100, Daniel Stenberg wrote: > >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