|
From: Peter T. <pt...@li...> - 2011-11-01 23:17:41
|
Hi all
Try to find the errors in this C/C++ snippet using valgrind:
#include <stdio.h>
/* 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...
Insure++ would for sure find the negative index, but GCC nor Valgrind
will get it...
Are there supplementary tools I should check? Or can I in some way
supplement my compile process so that valgrind could alert me?
Obviously I could augment the code so the the bad negative value of "i"
could be found from runtime specific parameters, i.e. static code
checking is not relevant for me.
Best
/pto
--
Peter Toft, PhD
http://petertoft.dk
|
|
From: Florian K. <br...@ac...> - 2011-11-02 00:28:45
|
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 <stdio.h>
> /* 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
> 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
|
|
From: Tom H. <to...@co...> - 2011-11-02 00:32:57
|
On 01/11/11 22:33, Peter Toft wrote:
> Try to find the errors in this C/C++ snippet using valgrind:
>
> #include<stdio.h>
> /* 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...
That's because you're using the wrong tool.
You're using the default memcheck tool, which will tell you about any
use of uninitialised data, but because you are dealing with stack
variables you have no gaps between your variables (with heap memory
valgrind would ensure there was a gap) so an out of bounds access is
likely to just access an adjacent (and defined) variable.
This should all be explained in the manual, which you probably want to
read to understand what memcheck will and won't find.
The tool that might find this problem is exp-ptrcheck (in the released
version) or exp-sgcheck (in the svn code). That specifically looks for
out of bounds access to stack variables by using the debug information
to discover the bounds.
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: Peter T. <pt...@li...> - 2011-11-02 07:36:13
|
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
|
|
From: Tom H. <to...@co...> - 2011-11-02 08:33:29
|
On 02/11/11 07:36, Peter Toft wrote: > Valgrind _does_ point to the problematic area - but finds the problem as > a unitialized values. Quite possible, depending on how the compiler chooses to arrange the stack. > 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? As I say, it's entirely up the compiler what order it places the variables in on the stack, and what padding it puts between them. That may well, for example, vary in 32 vs 64 bit mode in order to get the correct alignment of variables. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Peter T. <pt...@li...> - 2011-11-02 07:41:33
|
On Wed, 02 Nov 2011 00:32:44 +0000, Tom Hughes wrote:
> On
01/11/11 22:33, Peter Toft wrote:
>
>> 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...
> That's because you're using the wrong tool. You're using the
default memcheck tool, which will tell you about any use of
uninitialised data, but because you are dealing with stack variables you
have no gaps between your variables (with heap memory valgrind would
ensure there was a gap) so an out of bounds access is likely to just
access an adjacent (and defined) variable. This should all be explained
in the manual, which you probably want to read to understand what
memcheck will and won't find. The tool that might find this problem is
exp-ptrcheck (in the released version) or exp-sgcheck (in the svn code).
That specifically looks for out of bounds access to stack variables by
using the debug information to discover the bounds. Tom
He he - I knew
perfectly well, that I could not find this problem with the memcheck
tool, but wanted your input on how to cope with those problems.
Actually in the future I would wish that memcheck could be extended so
it could catch it - even if it would cost compile-time changes.
Valgrind is a great tool, but its user-value would increase quite a
bit, if it could catch a bit more (e.g. like my example).
Would it
possible to make this?
I will check exp-sgcheck in a sec - thanx Tom!
Best
/pto
--
Peter Toft, PhD
http://petertoft.dk
|
|
From: Tom H. <to...@co...> - 2011-11-02 08:34:37
|
On 02/11/11 07:41, Peter Toft wrote: > Actually in the future I would wish that memcheck could be extended so > it could catch it - even if it would cost compile-time changes. > > Valgrind is a great tool, but its user-value would increase quite a bit, > if it could catch a bit more (e.g. like my example). As we have explained, valgrind does support it, just in a different tool. There are performance reasons for keeping them separate because they operate in completely different ways. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Peter T. <pt...@li...> - 2011-11-02 08:31:26
|
On Wed, 02 Nov 2011 08:41:25 +0100, Peter Toft wrote:
> On Wed,
02 Nov 2011 00:32:44 +0000, Tom Hughes wrote:
>
>> On 01/11/11 22:33,
Peter Toft wrote:
>>
>>> 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...
>>
That's because you're using the wrong tool. You're using the default
memcheck tool, which will tell you about any use of uninitialised data,
but because you are dealing with stack variables you have no gaps
between your variables (with heap memory valgrind would ensure there was
a gap) so an out of bounds access is likely to just access an adjacent
(and defined) variable. This should all be explained in the manual,
which you probably want to read to understand what memcheck will and
won't find. The tool that might find this problem is exp-ptrcheck (in
the released version) or exp-sgcheck (in the svn code). That
specifically looks for out of bounds access to stack variables by using
the debug information to discover the bounds. Tom
>
> He he - I knew
perfectly well, that I could not find this problem with the memcheck
tool, but wanted your input on how to cope with those problems.
>
>
Actually in the future I would wish that memcheck could be extended so
it could catch it - even if it would cost compile-time changes.
>
>
Valgrind is a great tool, but its user-value would increase quite a bit,
if it could catch a bit more (e.g. like my example).
>
> Would it
possible to make this?
>
> I will check exp-sgcheck in a sec - thanx
Tom!
I cannot see exp-sgcheck catching anything (compiled from the SVN
version) :/
Best
/pto
--
Peter Toft, PhD
http://petertoft.dk
|
|
From: Tom H. <to...@co...> - 2011-11-02 10:19:24
|
On 02/11/11 10:18, Peter Toft wrote: > I cannot see tha that other two tools do much better on this kind of > coding problem. I see the same, which did surprise me a little. > Maybe that I do not give valgrind sufficient amount of options. Can you > comment? Well it is an experimental tool (hence the exp- prefix) so it isn't expected to be perfect yet. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Julian S. <js...@ac...> - 2011-11-02 10:57:14
|
On Wednesday, November 02, 2011 09:31:18 am Peter Toft wrote:
> #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;
> }
> I cannot see exp-sgcheck catching anything (compiled from the SVN
> version) :/
Yeah. That's because of the limitations of how sgcheck works. Have a
look at
http://www.valgrind.org/docs/manual/pc-manual.html#pc-manual.limitations
and specifically at the 4th bullet point ("Stack checks: It follows ...")
If you change your test program so that each memory referencing insn
iterates over an array and goes out of bounds, then it should get
spotted. But that's not the case here: each memory referencing insn
(for the various arrays) is only used once and so there's no opportunity
for the tool to infer which array each instruction is probably "supposed"
to access. (That probably won't make much sense until you read the
URL above ..)
J
|
|
From: Peter T. <pt...@li...> - 2011-11-02 11:41:00
|
On Wed, 2 Nov 2011 11:56:58 +0100, Julian Seward wrote:
> On
Wednesday, November 02, 2011 09:31:18 am Peter Toft wrote:
>
>>
#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; }
>
>> I cannot see exp-sgcheck catching
anything (compiled from the SVN version) :/
> Yeah. That's because of
the limitations of how sgcheck works. Have a look at
http://www.valgrind.org/docs/manual/pc-manual.html#pc-manual.limitations
[1] and specifically at the 4th bullet point ("Stack checks: It follows
...") If you change your test program so that each memory referencing
insn iterates over an array and goes out of bounds, then it should get
spotted. But that's not the case here: each memory referencing insn (for
the various arrays) is only used once and so there's no opportunity for
the tool to infer which array each instruction is probably "supposed" to
access. (That probably won't make much sense until you read the URL
above ..) J
Naturally I can easily redo that code so valgrind catches
the bug-type I show you e.g. by declaring the arrays via pointers and
allocating those with malloc/free, however I often find code from
Joe-average-designer or random-X-program, that the code style can
contain a mix of the errors valgrind currently is good at catching and
the ones I try to high-light in this mail-thread.
I would really like
to have an extended valgrind-workmode where the user can augment even
the compile process and/or link process, so the flow of valgrind could
also catch the mentioned kind of error.
Best
--
Peter Toft,
PhD
http://petertoft.dk
Links:
------
[1]
http://www.valgrind.org/docs/manual/pc-manual.html#pc-manual.limitations
|
|
From: Baurzhan I. <ib...@ra...> - 2011-11-02 12:35:14
|
On Tue, Nov 01, 2011 at 11:33:20PM +0100, Peter Toft wrote:
> 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]);
...
> Are there supplementary tools I should check?
There is also mudflap of gcc which claims to catch exactly this sort of
errors. It isn't perfect, either.
With kind regards,
Baurzhan.
|
|
From: Peter T. <pt...@li...> - 2011-11-02 12:55:57
|
On Wed, 2 Nov 2011 13:20:55 +0100, Baurzhan Ismagulov wrote:
> On
Tue, Nov 01, 2011 at 11:33:20PM +0100, Peter Toft wrote:
>> 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]);
> ...
>
>> Are there
supplementary tools I should check?
> There is also mudflap of gcc which
claims to catch exactly this sort of errors. It isn't perfect, either.
With kind regards, Baurzhan.
I might be mistaking here.... but if the
value if "i" is set from argv or alike then mudflap cannot help on this
problem.
Best
Peter
--
Peter Toft, PhD
http://petertoft.dk
|
|
From: Baurzhan I. <ib...@ra...> - 2011-11-02 13:34:31
|
On Wed, Nov 02, 2011 at 01:55:50PM +0100, Peter Toft wrote: > > There is also mudflap of gcc which claims to catch exactly this sort > > of errors. > > I might be mistaking here.... but if the value if "i" is set from argv > or alike then mudflap cannot help on this problem. It worked for me for overflows (e.g., i = 2) but not underflows (with -1 as in your original posting), regardless of how i has been set. That's interesting, I wasn't aware of that. With kind regards, Baurzhan. |
|
From: Jeffrey W. <nol...@gm...> - 2011-11-02 13:42:47
|
Hi Baurzhan, On Wed, Nov 2, 2011 at 9:34 AM, Baurzhan Ismagulov <ib...@ra...> wrote: > On Wed, Nov 02, 2011 at 01:55:50PM +0100, Peter Toft wrote: >> > There is also mudflap of gcc which claims to catch exactly this sort >> > of errors. >> >> I might be mistaking here.... but if the value if "i" is set from argv >> or alike then mudflap cannot help on this problem. > > It worked for me for overflows (e.g., i = 2) but not underflows (with -1 > as in your original posting), regardless of how i has been set. That's > interesting, I wasn't aware of that. Did you try Clang with UBC Integer Overflow Checker)? I don't believe its undefined behavior per se, but IOC might be able to flag it since its also a dynamic checker. http://embed.cs.utah.edu/ioc/. Jeff |
|
From: Baurzhan I. <ib...@ra...> - 2011-11-02 13:56:16
|
On Wed, Nov 02, 2011 at 09:42:41AM -0400, Jeffrey Walton wrote: > > It worked for me for overflows (e.g., i = 2) but not underflows (with -1 > > as in your original posting), regardless of how i has been set. That's > > interesting, I wasn't aware of that. > Did you try Clang with UBC Integer Overflow Checker)? I don't believe > its undefined behavior per se, but IOC might be able to flag it since > its also a dynamic checker. http://embed.cs.utah.edu/ioc/. Thanks for the hint, I'll have a look. With kind regards, Baurzhan. |
|
From: Dan K. <da...@ke...> - 2011-11-02 15:01:46
|
On Wed, Nov 2, 2011 at 6:55 AM, Baurzhan Ismagulov <ib...@ra...> wrote: > On Wed, Nov 02, 2011 at 09:42:41AM -0400, Jeffrey Walton wrote: >> > It worked for me for overflows (e.g., i = 2) but not underflows (with -1 >> > as in your original posting), regardless of how i has been set. That's >> > interesting, I wasn't aware of that. >> Did you try Clang with UBC Integer Overflow Checker)? I don't believe >> its undefined behavior per se, but IOC might be able to flag it since >> its also a dynamic checker. http://embed.cs.utah.edu/ioc/. > > Thanks for the hint, I'll have a look. Don't forget about gcc's -fstack-protector-all option. That can find a few things. |
|
From: Baurzhan I. <ib...@ra...> - 2011-11-02 20:18:26
|
On Wed, Nov 02, 2011 at 08:01:34AM -0700, Dan Kegel wrote: > Don't forget about gcc's -fstack-protector-all option. That can find > a few things. I've already tried this with the OP's example, didn't help. With kind regards, Baurzhan. |
|
From: Julian B. <ju...@pa...> - 2011-11-03 13:20:28
|
On 2011-11-01, Peter Toft <pt...@li...> wrote:
> Hi all
>
> Try to find the errors in this C/C++ snippet using valgrind:
>
> #include <stdio.h>
> /* 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
FWIW, GCC (4.6.1) finds this bug without trouble if you use -O2:
$ gcc -O2 -Wall loss.c -o loss
loss.c: In function ‘main’:
loss.c:5:22: warning: variable ‘c’ set but not used [-Wunused-but-set-variable]
loss.c:9:9: warning: array subscript is below array bounds [-Warray-bounds]
loss.c:9:9: warning: array subscript is below array bounds [-Warray-bounds]
Some warning analyses are only run at higher optimisation levels that -O0
(the default).
Jules
|
|
From: Peter T. <pt...@li...> - 2011-11-03 14:48:44
|
On Thu, 3 Nov 2011 11:09:34 +0000 (UTC), Julian Brown wrote:
> On
2011-11-01, 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
> FWIW, GCC
(4.6.1) finds this bug without trouble if you use -O2: $ gcc -O2 -Wall
loss.c -o loss loss.c: In function 'main': loss.c:5:22: warning:
variable 'c' set but not used [-Wunused-but-set-variable] loss.c:9:9:
warning: array subscript is below array bounds [-Warray-bounds]
loss.c:9:9: warning: array subscript is below array bounds
[-Warray-bounds] Some warning analyses are only run at higher
optimisation levels that -O0 (the default). Jules
------------------------------------------------------------------------------
RSA(R) Conference 2012 Save 0 by Nov 18 Register now
http://p.sf.net/sfu/rsa-sfdev2dev1 [2]
_______________________________________________ Valgrind-users mailing
list Val...@li... [3]
https://lists.sourceforge.net/lists/listinfo/valgrind-users [4]
small
twist to the code, then gcc -O2 -Wall finds nothing....
See the
comment -> run as "code -1"
#include
#include
/* Save as code.c
compile "gcc -Wall -O2 o code code.c" and run as "code -1" */
int
main(int argc, char **argv)
{
int a[2],b[2],c[2],i;
a[0] = 1; a[1] =
2;
b[0] = 3; b[1] = 4;
c[0] = 5; c[1] = 6;
printf("Dummy print ....
%in",c[0]);
printf("argv[1] = %sn",argv[1]);
i = atoi(argv[1]);
printf("index i = %in",i);
printf("%i %in",b[i],a[i]);
return 0;
}
--
Peter Toft, PhD
http://petertoft.dk
Links:
------
[1]
mailto:pt...@li...
[2] http://p.sf.net/sfu/rsa-sfdev2dev1
[3]
mailto:Val...@li...
[4]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Dan K. <da...@ke...> - 2011-11-03 15:58:47
|
On Thu, Nov 3, 2011 at 7:48 AM, Peter Toft <pt...@li...> wrote:
> small twist to the code, then gcc -O2 -Wall finds nothing....
>
> See the comment -> run as "code -1"
>
> #include <stdio.h>
> #include <stdlib.h>
>
>
> /* Save as code.c compile "gcc -Wall -O2 o code code.c" and run as "code
> -1" */
> int main(int argc, char **argv)
> {
> int a[2],b[2],c[2],i;
>
> a[0] = 1; a[1] = 2;
> b[0] = 3; b[1] = 4;
> c[0] = 5; c[1] = 6;
>
>
> printf("Dummy print .... %i\n",c[0]);
> printf("argv[1] = %s\n",argv[1]);
> i = atoi(argv[1]);
> printf("index i = %i\n",i);
> printf("%i %i\n",b[i],a[i]);
> return 0;
> }
I recently found a real bug like this with valgrind
( see http://bugs.winehq.org/show_bug.cgi?id=25826,
in which the bug was caught because it ended up
causing an overlapping memcpy ). So it's worth
trying valgrind. And, luckily, Valgrind accidentally finds
something to complain about here (though it doesn't
point straight to the line in main() that causes it):
$ gcc -Wall -g -O2 -o code code.c
$ valgrind ./code -1
Dummy print .... 5
argv[1] = -1
index i = -1
Use of uninitialised value of size 4
at 0x4083B2B: _itoa_word (_itoa.c:195)
by 0x4087E55: vfprintf (vfprintf.c:1619)
by 0x412A054: __printf_chk (printf_chk.c:37)
2 68928292
- Dan
|