|
From: tom f. <tf...@al...> - 2009-02-13 17:09:55
|
Micah N Gorrell <val...@mi...> writes:
> Doesn't `definedness' propagate in valgrind? Further, as I remember
> > you would only see an issue when the uninitialized value directed a
> > computation, or was output.
> >
> > For example:
> >
> > 1 int m(int x) {
> > 2 return x + 42;
> > 3 }
> > 4 int main() {
> > 5 int y;
> > 6 int z = 19;
> > 7 z = m(y);
> > 8 if(z > 50) {
> > 9 puts("big z!");
> > 10 }
> > 11 return 0;
> > 12 }
> >
> > As I remember, valgrind would complain about line 8 here, *not* line 7.
> > (Please somebody correct me if I'm wrong! :)
> >
> > That said, is it possible that one of your arguments to SSL_read is
> > uninitialized? If you throw a printf on those args on the line before
> > the call, does valgrind complain at the printf?
> >
> > -tom
> >
>
> That is a REALLY useful example. I've been having a bit of hard
> time with th e way valgrind reports uninitialized variables, since
> it isn't complaining abou t them being passed around. It is very
> different from what a compiler would wa rn about for example.
Glad it helped.
You might find the --track-origins=yes option useful. After I sent
that mail, I actually tried it on the above program [1], and valgrind
was able to tell me that the unitialized value was sourced from the
stack variable `y'. The option exists in 3.4.0.
Best,
-tom
[1] -ish. I actually forgot an include in the above, of course.
|