Re: "failed to read delta base object at..."

[Nicolas Pitre <nico@cam.org>]

On Wed, 27 Aug 2008, Linus Torvalds wrote:

> 
> 
> On Tue, 26 Aug 2008, Jason McMullan wrote:
> > 
> > All bets are off when data=writeback.
> 
> Not the way git writes pack-files. It does a fsync() before moving them 
> into place (at least newer git versions do), so the data is stable.

And isn't the bad data block size and alignment a bit odd for a 
filesystem crash corruption?

> I do worry about wild pointers. I can't recognize the data, and it 
> definitely doesn't look like any git internal data structures, but 16-bit 
> data _is_ what zlib internally uses for things like the decoding tables. 
> 
> 
> So if there is some use-after-free issue, I could imagine things like this 
> happening inside of git. People do occasionally run valgrind on git, 
> though, and it's been clean in the past, but I don't know if that has ever 
> been done on the threaded packing, for example.

However, in the pack-objects case, it is almost impossible to have such 
a corruption since the data is SHA1 summed immediately before being 
written out.  In the index-pack case, it is even less likely since the 
data is SHA1 summed immediately after being written out.  So there is no 
window for random pointer access corrupting the data without also 
influencing the pack checksum outcome.  Therefore, if the pack content 
doesn't match its checksum, then the corruption must have occurred 
outside of git, otherwise the checksum would have included corrupted 
data already and the pack checksum would match.


Nicolas