On Tue, 01 Nov 2011 20:28:34 -0400, Florian Krohm wrote:
> On
11/01/2011 06:33 PM, Peter Toft wrote:
>> Hi all
>>
>> Try to find the
errors in this C/C++ snippet using valgrind:
>>
>> #include
>> /* Save
as code.c */
>> int main(void)
>> {
>> int i=-1,a[2],b[2],c[2];
>> a[0]
= 1; a[1] = 2;
>> b[0] = 3; b[1] = 4;
>> c[0] = 5; c[1] = 6;
>>
printf("%i %in",b[i],a[i]);
>> return 0;
>> }
>>
>> Compile using "gcc
-o bla code.c -Wall" and check the code using
>> "valgrind ./bla".
>>
Valgrind finds nothing even though I index a[-1] and b[-1] - not
>>
good...
>
> Not good. But expected. Memcheck, the default valgrind
tool, does not
> find array overruns on variables allocated on the
stack.
> You might want to try ptrcheck:
>
http://valgrind.org/docs/manual/pc-manual.html#pc-manual.how-works.sg-checks
[1]
>
>> Insure++ would for sure find the negative index, but GCC nor
Valgrind
>> will get it...
>
> It's lame that GCC does not find it.
Try clang. I wouldn't be surprised,
> if it catches this error but I
haven't tried it.
>
> Florian
Hey - this ones gets more funny....
If
I run gcc+valgrind in 32 bit, then I get nothing (as shown above), but
for 64 bit GCC (valgrind-3.6.0 and gcc 4.4.3 ) the game changes:
==21319== Use of uninitialised value of size 8
==21319== at
0x3A9EC419BD: _itoa_word (in /lib64/libc-2.5.so)
==21319== by
0x3A9EC44E5A: vfprintf (in /lib64/libc-2.5.so)
==21319== by
0x3A9EC4D3F9: printf (in /lib64/libc-2.5.so)
==21319== by 0x400502: main
(in /renesas/co_rme/home/petoft/c/ged)
==21319==
==21319== Conditional
jump or move depends on uninitialised value(s)
==21319== at
0x3A9EC419C7: _itoa_word (in /lib64/libc-2.5.so)
==21319== by
0x3A9EC44E5A: vfprintf (in /lib64/libc-2.5.so)
==21319== by
0x3A9EC4D3F9: printf (in /lib64/libc-2.5.so)
==21319== by 0x400502: main
(in /renesas/co_rme/home/petoft/c/ged)
==21319==
==21319== Conditional
jump or move depends on uninitialised value(s)
==21319== at
0x3A9EC44ED4: vfprintf (in /lib64/libc-2.5.so)
==21319== by
0x3A9EC4D3F9: printf (in /lib64/libc-2.5.so)
==21319== by 0x400502: main
(in /renesas/co_rme/home/petoft/c/ged)
==21319==
==21319== Conditional
jump or move depends on uninitialised value(s)
==21319== at
0x3A9EC4563F: vfprintf (in /lib64/libc-2.5.so)
==21319== by
0x3A9EC4D3F9: printf (in /lib64/libc-2.5.so)
==21319== by 0x400502: main
(in /renesas/co_rme/home/petoft/c/ged)
==21319==
==21319== Conditional
jump or move depends on uninitialised value(s)
==21319== at
0x3A9EC43B60: vfprintf (in /lib64/libc-2.5.so)
==21319== by
0x3A9EC4D3F9: printf (in /lib64/libc-2.5.so)
==21319== by 0x400502: main
(in /renesas/co_rme/home/petoft/c/ged)
==21319==
Valgrind _does_ point
to the problematic area - but finds the problem as a unitialized values.
I did not know that the values I get with my example is different from
32 bit to 64 bit systems.
Apparently the memory stacking works
differently. Anyone who can explain this?
Regarding your hint about
trying "valgrind tool=exp-ptrcheck ./bla", I get many blocks of this
kind (see just below) - that I actually do not understand (on 64 bit).
==27351== Invalid read of size 4
==27351== at 0x52D914:
_IO_default_setbuf (in /lib/libc-2.5.so)
==27351== by 0x52C6BF:
_IO_file_setbuf@@GLIBC_2.1 (in /lib/libc-2.5.so)
==27351== by 0x52EA70:
_IO_cleanup (in /lib/libc-2.5.so)
==27351== by 0x4F4D62: exit (in
/lib/libc-2.5.so)
==27351== by 0x4DEEA3: (below main) (in
/lib/libc-2.5.so)
==27351== Address 0x60b554 is not derived from any
known block
==27351== Address 0x60b554 is 148 bytes inside data symbol
"_IO_2_1_stdout_"
==27351==
those clutter the general findings.
Best
/pto
--
Peter Toft, PhD
http://petertoft.dk
Links:
------
[1]
http://valgrind.org/docs/manual/pc-manual.html#pc-manual.how-works.sg-checks
------------------------------------------------------------------------------
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
