Re: Fw: git-core: SIGSEGV during {peek,ls}-remote on HTTP remotes.

From: Clemens Buchacher <drizzd@aon.at>
Date: Nov 2, 2009, 19:21 UTC
Message-ID: <20091102192145.GA12718@localhost>
In-Reply-To: <alpine.LNX.2.00.0911011829130.14365@iabervon.org>

On Sun, Nov 01, 2009 at 07:59:45PM -0500, Daniel Barkalow wrote:

Show 9 quoted lines

> I've been looking at it, just now, and I might try to clean stuff up. The 
> problem I'm running into is that, in some cases, you have to call 
> setup_git_directory_gently(), and it might determine that there is no git 
> repo, but then the various environment functions don't distinguish between 
> the situation where you haven't called it at all and the situation where 
> you called it and determined there to be no answer. Furthermore, a lot of 
> functions seem to be getting git_path(something), ignoring the fact that 
> there is no repo, and acting like there is a repo that has simply not got 
> the file it is looking for.

Indeed. In particular, you can cause most git commands which take a path argument to segfault in GIT_DIR:

$ git grep -- / Segmentation fault

$ git ls-files / Segmentation fault

$ git show HEAD / Segmentation fault

$ git diff HEAD / Segmentation fault

You get the idea. It looks like at some point each of these calls get_git_work_tree(), which returns NULL. I was trying to fix it this weekend but got confused by the setup api (to be documented in Documentation/technical/api-setup.txt). I don't think fixing all the callers of get_git_work_tree() is the right thing to do. Instead, we should die() if there is no work tree and a different function should be used to check whether or not a work tree exists.

I will try to understand this convoluted codepath when I have gathered the patience to do it. But while you're looking at it, maybe you can also take this issue into consideration.

Thanks, Clemens