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

From: Nicolas Pitre <nico@cam.org>
Date: Aug 27, 2008, 19:17 UTC
Message-ID: <alpine.LFD.1.10.0808271458320.1624@xanadu.home>
In-Reply-To: <alpine.LFD.1.10.0808270937340.3363@nehalem.linux-foundation.org>

On Wed, 27 Aug 2008, Linus Torvalds wrote:

Show 8 quoted lines

> 
> 
> 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?

Show 9 quoted lines

> 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