Re: segfault in git-remote-http

From: rh <richard_hubbe11@lavabit.com>
Date: Apr 10, 2013, 19:16 UTC
Message-ID: <20130410121625.7424bede4b3706c27e1388c1@lavabit.com>
In-Reply-To: <20130410185114.GA18084@sigill.intra.peff.net>

On Wed, 10 Apr 2013 14:51:15 -0400 Jeff King <peff@peff.net> wrote:

Show 17 quoted lines

> On Wed, Apr 10, 2013 at 09:08:50AM -0700, rh wrote:
> 
> > > which should show both program names. Git invokes git-remote-*
> > > based on the URL you fed it. So if you are seeing a segfault in
> > > git-remote-http, presumably you fed it an http URL (which may
> > > still execute SSL code if it redirects to an https URL).
> > 
> > Here's the command I ran (from initial post):
> > git clone https://github.com/bitcoin/bitcoin.git
> > 
> > This returns no error on the command line and produced the segfault
> > reported by the kernel. git clone returns immediately.
> 
> It does correctly report a failed exit code. The lack of message is
> because git assumes that the helper will produce a useful message
> before dying, but obviously it doesn't.  There's already a patch[1]
> to fix this, but it hasn't been merged yet.

Oh yeah, I didn't check $? but I got sidetracked seeing the segfault.

Show 6 quoted lines

> 
> As for why dmesg reports git-remote-http, I'm not sure. If you "strace
> -f" the command, you can see that git is running git-remote-https. Why
> the kernel chooses to report "git-remote-http", I don't know; you'd
> have to look into how the kernel makes that decision. But I doubt it
> is related to the reason for the segfault in the first place.

This could be that it's using the first match or entry in the hardlink list. Which seems like a bad idea ... but that's a wild guess.

I agree it seems unlikely that it's related to the segfault.