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.

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

Reply via email to