On Thu, Aug 28, 2014 at 04:14:01PM -0700, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > On Thu, Aug 28, 2014 at 06:08:21PM -0400, Jeff King wrote: > > > >> Interesting. I couldn't convince Helgrind to catch such a case... > > > > Ugh. It helps if you actually helgrind the git binary, and not the > > shell-script from bin-wrappers. I can easily replicate the problem now. > > The patch I just posted seems to fix it (at least it has been running in > > a loop for over a minute with no failures, whereas before it took only a > > few seconds to provoke a failure). > > Thanks for digging. I'll pick it up and may comment on it in > tomorrow's cycle (it is a bit too late for today's cycle, > unfortunately).
Here's a proposed series. [1/2]: index-pack: fix race condition with duplicate bases [2/2]: index-pack: handle duplicate base objects gracefully There are two big changes from what has been posted already: 1. While writing up the commit message, I realized that this can't ever happen for OFS_DELTA (neither the race condition, nor the duplicate resolution) because offsets by definition point to a unique entry in our object_entry array. So even if we have multiple copies of the base object in the pack, there's only one possible base for an OFS_DELTA. 2. René's original patch just does nothing for a delta which has already been resolved, and continues through the function to try any OFS_DELTA objects. If there isn't one, we return NULL to say "nothing left to resolve". But that's not quite true. There may have been other REF_DELTA against the same base, but we never incremented our counter to find it. Instead, we need to actually increment our counter and loop again to see if there's another REF_DELTA to handle. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html