On Tue, Mar 19, 2013 at 11:29:36AM +0100, Thomas Rast wrote:
> > 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
--
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