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

On Tue, 26 Aug 2008, Jason McMullan wrote:

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.

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.

For example, the corrupting data had patterns like this:

	00 f8 bf fe 6b 57 fe ff 55 57 fe ff 97 57 fe ff

where the pattern _could_ be something like

	{ 00 f8 febf },
	{ 6b 57 fffe },
	{ 55 57 fffe },
	{ 97 57 fffe },

assuming that the "fe ff" pattern really is meaningful and is a 16-bit little-endian word.

And the thign is, zlib "code" tables look exactly like that:

	typedef struct {
	    unsigned char op;           /* operation, extra bits, table bits */
	    unsigned char bits;         /* bits in this part of the code */
	    unsigned short val;         /* offset in table or code value */
	} code;

	/* op values as set by inflate_table():
	    00000000 - literal
	    0000tttt - table link, tttt != 0 is the number of table index bits
	    0001eeee - length or distance, eeee is the number of extra bits
	    01100000 - end of block
	    01000000 - invalid code
	 */

but those particular op/val things don't make sense in that context either. But I don't know zlib that well, maybe the deflate routines use some other model.

			Linus