On Thu, 24 Apr 2014, Jeff King wrote:
Thanks, that's very helpful. I wasn't able to reproduce your problem
locally, but I suspect the curl patch below may fix it:
...
Daniel, I think the similar fix to curl_multi_cleanup in commit a900d45
missed this code path, and we need something like the
On Thu, Apr 24, 2014 at 12:15 AM, Jeff King wrote:
> I suspect the curl patch below may fix it:
>
> diff --git a/lib/multi.c b/lib/multi.c
> index bc93264..72e4825 100644
> --- a/lib/multi.c
> +++ b/lib/multi.c
> @@ -1804,10 +1804,13 @@ static void close_all_connections(struct Curl_multi
> *multi
On Wed, Apr 23, 2014 at 07:49:09AM -0400, Greg M wrote:
> > The easiest way to find it is probably to attach a debugger to the
> > running git-remote-https, and get a backtrace when it dies from SIGPIPE.
> > You'll probably want to install your system's debug packages for curl,
> > too.
> >
>
> T
On Wed, Apr 23, 2014 at 2:59 AM, Jeff King wrote:
> On Sun, Apr 20, 2014 at 08:42:15PM -0400, Greg M wrote:
>
>> Using git version 1.9.2 I am getting this error:
>>
>> [normal@laptop tmp]$ git clone https://github.com/mozilla/rust.git
>> Cloning into 'rust'...
>> remote: Reusing existing pack: 296
On Sun, Apr 20, 2014 at 08:42:15PM -0400, Greg M wrote:
> Using git version 1.9.2 I am getting this error:
>
> [normal@laptop tmp]$ git clone https://github.com/mozilla/rust.git
> Cloning into 'rust'...
> remote: Reusing existing pack: 296648, done.
> remote: Counting objects: 80, done.
> remote:
On Mon, Nov 25, 2013 at 09:32:13AM -0500, Jeff King wrote:
> > 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 th
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
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
On Sun, Nov 24, 2013 at 05:32:34PM +0100, Stefan Beller wrote:
> 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), d
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 (a
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 proble
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
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 pro
[+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 clo
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
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 connectivit
On 24.11.2013 07:54, Jeff King wrote:
> 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)
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), r
18 matches
Mail list logo