Re: fact-import: failed to apply delta
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Feb 10, 2009, 21:32 UTC
- Message-ID
- <alpine.LNX.1.00.0902101628140.19665@iabervon.org>
- In-Reply-To
- <20090210212539.GV30949@spearce.org>
On Tue, 10 Feb 2009, Shawn O. Pearce wrote:
Show 25 quoted lines
> Daniel Barkalow <barkalow@iabervon.org> wrote: > > > > I think maybe there's aliasing in the delta base cache? If it recycled a > > struct packed_git, the cache would come up with a cached tree at offset 12 > > of the packed_git at that address, but the pack used by that struct has > > changed. > > Yup, that must be it. > > > I don't see any reason that the situation couldn't arise where you start a > > pack, look up an object in it while it's still open but the object isn't > > in the window, cache the delta base, end that packfile, eventually start a > > packfile that gets allocated in the space that was freed, produce a new > > delta against the object at exactly the same offset of the new pack (with > > the same address as the old pack), and go on happily until you try looking > > up this last delta and pull the wrong base out of the cache. > > > > I don't see any code to flush the delta cache ever, but it's hard to get a > > new packed_git allocated at the address of a freed one, except by doing a > > lot of checkpoints in fast-import... > > *ouch*. I think you found it. > > We should dump the cached_objects table in sha1_file.c during > a checkpoint in fast-import.
No, that one's keyed by sha1, and doesn't get collisions; it's the delta_base_cache that's the issue; it's keyed by struct packed_git * and offset.
-Daniel *This .sig left intentionally blank*