Re: [PATCH] sha1_name: fix segfault caused by invalid index access

From: Jeff King <peff@peff.net>
Date: Feb 28, 2010, 16:25 UTC
Message-ID: <20100228162550.GA7315@coredump.intra.peff.net>
In-Reply-To: <1267372155-7578-1-git-send-email-markus.heidelberg@web.de>

On Sun, Feb 28, 2010 at 04:49:15PM +0100, Markus Heidelberg wrote:

Show 6 quoted lines

> It can be reproduced in a bare repository with
>     $ git show :anyfile
> 
> I didn't find a recipe for reliably reproducing it in a repository with
> working tree, it happened depending on the filename and the repository.
>     $ git show :nonexistentfile

I can confirm the bug here. It is not about bareness, but having no index makes it easy to trigger, since it is easy to walk past the end of a zero-length index. But it is not restricted to that case:

> It seemed to happen more likely with high letters (x, y, z) as the first
> character of the filename. This always worked for me:
>     $ git show :z
> But I found this to be too strange to be added to the commit message.

That's because cache_name_pos returns the position where the entry _would_ be if it existed (well, the negation minus one, but the intent is you can reconstruct that position if you did want to insert it). The diagnose_invalid function then looks at that entry to see if it is a missing filename or a missing stage. But of course, if it would be inserted past the end of what exists in the index, there is nothing to look at. So your ":z" is simply about being at the end of the index, which is sorted alphabetically.

Which means your fix (to make sure we are not at the end) is correct.

-Peff