Markus Heidelberg <markus.heidelberg@xxxxxx> writes: > 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 > 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 It happens when you ask for a filename that is after the last index entry by alphabetical order, yes. pos will contain an index which is after the previous entry, that is, after the last entry. And then, the active_cache[pos] crashes. > The affected code path was introduced by commit 009fee477 (Detailed diagnosis > when parsing an object name fails., 2009-12-07). Yes, my bad :-(. Thanks for the report and the fix :-). > pos = cache_name_pos(filename, namelen); > if (pos < 0) > pos = -pos - 1; Actually, if pos < 0, then cache_name_pos didn't find the entry, and we shouldn't try any complex thing to find out. A simpler fix is comming in a separate email. I'm still not familiar enough with the index to be 100% confident, but it should do the same as yours in a much simpler way. Reviews welcome. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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