Re: fact-import: failed to apply delta

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Feb 10, 2009, 20:03 UTC
Message-ID: <alpine.LNX.1.00.0902101427300.19665@iabervon.org>
In-Reply-To: <20090210191220.GT30949@spearce.org>

On Tue, 10 Feb 2009, Shawn O. Pearce wrote:

Show 14 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> wrote:
> > 
> > Actually, I went for the other end; I made close_pack_windows() not mind 
> > the open windows (hey, it's dying anyway in my case, nobody's going to 
> > write more), and the results passed verification and "git fsck --full" 
> > with just a few dangling blobs and a dangling commit. So it seems to me 
> > that it has to be wrong information in memory.
> 
> Like the wrong offset within the pack for the object start?
> 
> Can you compare the offsets you are getting during
> unpack_delta_entry() against what verify-pack -v
> shows for the same file?  They should agree, unless
> we're somehow wrong in memory within fast-import.

Is there some easy way to tell what object it was having problems with when it failed to unpack? I've got a whole lot of objects.

On the other hand, there's something interesting:

The expected size of the base is 1882, while the actual size is 151. The base offset it found was 12.

I'm using "checkpoint" a lot, so I've got 24 packs. Two of them have tree objects of size 1882 at offset 12; a different one has a tree object of size 151 at offset 12. The one with the object of size 151 was the one that was still open at the end. There's no tree of size 1882 in this pack, nor in any other pack that has a tree of size 151.

So maybe it's right about the offsets and all, but it's confused about which pack something was in? Maybe it cached something when the pack containing the object it wants was open, and it ended up thinking it was in the pack that's now open rather than the pack that was open and is now closed?

I don't suppose there would be an easy way to figure out the object it was trying to unpack by applying the delta?

> But then, the output pack-*.idx file created when
> fast-import closed the pack would be wrong too.

I think the wrong info it has is about the contents of a pack that had been closed previously. I think all of the info about objects in the open pack is correct.

	-Daniel
*This .sig left intentionally blank*