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

quoted text
> 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*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html