I hope you'll forgive me pushing your reply back to the list. Please
try to keep the ML in the loop, so that any solutions get archived.
Brian Wainscott <[EMAIL PROTECTED]> writes:
>
> Yeah, I know, which makes tracking these things down a pain. Like I
> said, this example isn't perfect.
*shrug*, yes. I imagine it is a performance tradeoff -- the branch
incurred for checking every access isn't worth it, if one can show
that the invalid code will never cause a problem.
I'm no valgrind developer, but `code speaks louder than words'...
> But I'm still seeing LOTS of these which I didn't see in earlier
> versions of valgrind (circa. 2 years ago, I don't remember the
> version number).
Why is this an issue? This code is \emph{wrong}. It doesn't matter
that valgrind didn't notice until it was passed into printf. If
earlier versions of valgrind did not report this error, then earlier
versions of valgrind are buggy.
Certainly it would be nicer if memcheck could check all the arguments
to printf and give out a warning upon the call instead of upon the
access. That would require valgrind to be a higher level tool than I
get the impression it is.
> And I DON'T understand why they all complain about 8 byte sizes when
> all my data is 4 bytes....
Last I checked (1.5[?] years ago), gcc conformed to an x86_64 ABI which
said arguments are passed in 8-byte locations on the stack. I can
imagine it also reserves 8 bytes for the return value as well (even if
the return value is smaller, that is).
I guess the next step would be examining the assembly to verify. I'll
leave that as an excercise for the reader ;)
-tom
> tom fogal wrote:
> > Brian Wainscott <[EMAIL PROTECTED]> writes:
> >> #include <stdio.h>
> >> main()
> >> {
> >> int i,j;
> >>
> >> for(i=j=0; i< 5; i++) {
> >> j=do_sub(j);
> >> }
> >>
> >> printf("Result = %d\n",j);
> >> }
> >> int do_sub(int in)
> >> {
> >> int out;
> >> //int junk=1; /* No errors */
> >> int junk; /* Errors */
> >>
> >> out = in+junk;
> >> return out;
> >> }
> >>
> >> has an obvious error ("junk" is not initialized). When I build this on my
>
> >> OpenSuSE 11.0 x86_64 system with the gcc 4.3.1 compiler, I either get no
> >> valgrind errors (if junk=1 is used), or I get this (when junk is not
> >> initialized):
> >>
> >> ==22349== Use of uninitialised value of size 8
> >> ==22349== at 0x4E6E423: (within /lib64/libc-2.8.so)
> >> ==22349== by 0x4E7166F: vfprintf (in /lib64/libc-2.8.so)
> >> ==22349== by 0x4E78FE9: printf (in /lib64/libc-2.8.so)
> >> ==22349== by 0x40055E: main (in /home/brian/tmp/tst)
> >>
> >> Now, this "error" is in the system libraries, and I don't KNOW that the
> >> error report is wrong. But I don't get ANY errors about the usage of junk
> ,
> >> or anything else.
> >
> > Errors are not reported until they are `visible'. The
> > uninitialized-ness of junk propagates to do_sub:out, and then main:j,
> > but it is only upon the observed access in the printf that the
> > uninitialized nature of main:j is visible.
> >
> > See:
> >
> > http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.value
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
