On Wed, 10 Apr 2013 14:51:15 -0400 Jeff King <peff@xxxxxxxx> wrote: > 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. > > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html