Re: regression in multi-threaded git-pack-index

From: Jeff King <peff@peff.net>
Date: Mar 19, 2013, 10:33 UTC
Message-ID: <20130319103306.GA9490@sigill.intra.peff.net>
In-Reply-To: <87obef8yy7.fsf@pctrast.inf.ethz.ch>

On Tue, Mar 19, 2013 at 11:29:36AM +0100, Thomas Rast wrote:

Show 12 quoted lines

> > Ah, indeed. Putting:
> >
> >   fprintf(stderr, "%lu\n", base->obj->delta_depth);
> >
> > before the conditional reveals that base->obj->delta_depth is
> > uninitialized, which is the real problem. I'm sure there is some
> > perfectly logical explanation for why valgrind can't detect its use
> > during the assignment, but I'm not sure what it is.
> 
> That's simply because you would get far too much noise.  It only reports
> an uninitialized value when it actually gets used in a conditional or
> for output (syscalls), which is when they matter.

Would it? I would think any computation you start with an undefined value would be suspect (and you would want to know about it as soon as possible, before the tainted value gets output). I was assuming it was a performance issue or something.

> You can use --track-origins=yes to see where the undefined value came
> from, but it's veeeery slow.

It's pretty slow either way. :) I do have --track-origins on, but the origin is this:

  objects = xrealloc(objects,
                     (nr_objects + nr_unresolved + 1)
                     * sizeof(*objects));

which is not very helpful. It's _somewhere_ in the list of objects...:)

-Peff