git fsck segmentation faultrectories

Question

I'm using git in Rubymine. After another commit I opened git push window and saw object file .git/object/55/4d...e6 is emptyunable to read .... instead of the commit name.

Running git fsck -full gives me this: Segmentation faultrectories: 33% (85/256)

Is there anything I can do here?

Answer 1

Git 2.25 (Q1 2020) should address one possible git fsck segfault cause.
That command has crufty code and logic accumulated over time around the object parsing and low-level object access, which is being fixed.

See commit b2f2039, commit c5b4269, commit 103fb6d, commit f648ee7, commit cc57900, commit 7854399, commit b8b00f1, commit 6da40b2, commit 3837025, commit f597937, commit 5afc4b1, commit 82ef89b, commit 7339029, commit d40bbc1, commit a59cfb3, commit 23a173a, commit 2175a0c, commit ec65231, commit 1de6007, commit 78d5014, commit 12736d2, commit c78fe00 (18 Oct 2019), and commit 228c78f (25 Oct 2019) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 0e07c1c, 01 Dec 2019)}

parse_commit_buffer(): treat lookup_commit() failure as parse error

^{Signed-off-by: Jeff King}

While parsing the parents of a commit, if we are able to parse an actual oid but lookup_commit() fails on it (because we previously saw it in this process as a different object type), we silently omit the parent and do not report any error to the caller.

The caller has no way of knowing this happened, because even an empty parent list is a valid parse result. As a result, it's possible to fool our "rev-list" connectivity check into accepting a corrupted set of objects.

That leads to:

parse_tag_buffer(): treat NULL tag pointer as parse error

^{Signed-off-by: Jeff King}

When parsing a tag, we may end up with a NULL "tagged" field when there's a type mismatch (e.g., the tag claims to point to object X as a commit, but we previously saw X as a blob in the same process), but we do not otherwise indicate a parse failure to the caller.

This is similar to the case discussed in the previous commit, where a commit could end up with a NULL tree field: while slightly convenient for callers who want to overlook a corrupt object, it means that normal callers have to explicitly deal with this case (rather than just relying on the return code from parsing).
And most don't, leading to segfault fixes like the one in c77722b3ea ("use get_tagged_oid()", 2019-09-05, Git v2.24.0-rc0 -- merge listed in batch #4).

Let's address this more centrally, by returning an error code from the parse itself, which most callers would already notice (adventurous callers are free to ignore the error and continue looking at the struct).

This also covers the case where the tag contains a nonsensical "type" field (there we produced a user-visible error but still returned success to the caller; now we'll produce a slightly better message and return an error).

As part of the better error messages:

• no more segfault
• bad tag pointer to 'xxx' in yyy'
• or: unknown tag type 'xxx' in yyy