Runtime security/memory checks for gcc/gdb

[Elazar Leibovich]

On Tue, Jan 12, 2010 at 8:02 AM, Shachar Shemesh <shachar at shemesh.biz>wrote:

>  Elazar Leibovich wrote:
>
> I tried using valgrind in a different project. The main problems I've had
> with valgrind are speed
>
> Yes, that is known.
>
>  and false positives.
>
> That one is new to me. Can you elaborate?
>
IIRC the problem was using a different library, and tracing which problems
are yours and which are of the library.
See for instance this rant
http://www.mega-nerd.com/erikd/Blog/CodeHacking/house_of_cards.html
I haven't really got into this, so maybe the suprresion files does allow you
to quickly fix it.

>
>  Getting gdb to report that during runtime has its advantages.
> Anyhow, I was hoping to hear about products/valgrind add-ons etc I do not
> know.
>
> The main practical problem with it, is convincing management that getting a
> linux box or VM and build the code on it is worth our while...
>
> Personally, I think that you should start with gcc. Just because it spews
> out thousands of warnings does not mean they are not all relevant. Compiler
> warnings are the easiest to fix, easiest to find, and are often written off
> for no justifiable reason.
>
It's more complex than that. The code currently work on the embedded device.
This is a mission critical device, so we cannot make changes to the runtime
code without testing it throughly first.
I try therefor to fix the problem in the emulation level without touching
the actual code. (for instance, overriding a certain problematic function
which used an uninitialized variable, and got away with it in the embedded
device, but not in the desktop, or, replace the macro which stores a
specific memory address (hex number) which is used by a the code, and is
obviously relevant only for the embedded device)
Having a good runtime error checks (such as valgrind) will help me with
recognizing this anomalities.

>
> I'm not sure at which version this started, but gcc 4.4.2 with -Wextra
> catches your second example (array bounds problem).
>
That surprising, more complex instances could be reducable to the halting
problem (number of times we advance p might depend on any complex function).
Didn't work for me. (Does it check that during runtime? perhaps it doesn't
work with mingw).

Leibo at Leibo-PC ~
$ cat tmp.c
int main(int argc,char **argv) {
    int x[10],y[10],i=0;
    int *p = x;
    for (;i<=13;i++,p++) *p = (*p)++;
    return 0;
}

Leibo at Leibo-PC ~
$ /cygdrive/c/MinGW/bin/gcc.exe --version
gcc.exe (TDM-2 mingw32) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Leibo at Leibo-PC ~
$ /cygdrive/c/MinGW/bin/gcc.exe -Wextra -Wall tmp.c
tmp.c: In function 'main':
tmp.c:2: warning: unused variable 'y'
tmp.c:1: warning: unused parameter 'argc'
tmp.c:1: warning: unused parameter 'argv'


> Shachar
>
> --
> Shachar Shemesh
> Lingnu Open Source Consulting Ltd.http://www.lingnu.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20100112/31778ae3/attachment.html>