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