On Thu, Aug 28, 2014 at 04:14:01PM -0700, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html