On Tue, Jan 12, 2010 at 8:02 AM, Shachar Shemesh <[email protected]>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). le...@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; } le...@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. le...@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 > >
_______________________________________________ Linux-il mailing list [email protected] http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
