Valgrind is a tool that helps you find memory management problems in Linux programs. From the 3.3.0 log: Helgrind works again with improved race detection and better error messages. Massif generates better output. Cachegrind has been extended to do branch-misprediction profiling. Both conditional and indirect branches are profiled. Scalability has been improved for very large programs, particularly those with a million or more malloc'd blocks in use at once. These improvements mostly affect Memcheck, which is also up to 10% faster for all programs, with x86 Linux seeing the largest improvement. The documentation has been reorganized. Experimental tools have been added, and more.
Post a Comment
Member since:
2007-09-12
Member since:
2005-08-30
Member since:
2006-01-22
Member since:
2005-12-31
Member since:
2006-03-02
Member since:2005-07-20
Works fine on my FreeBSD box, and I would assume it works fine on NetBSD, especially considering its on the experimental list at http://valgrind.org/info/platforms.html
Member since:2006-03-02
Member since:2007-12-28
Unfortunately, at this point the netbsd port is still on hold.
Time is very scarce for me at this point to continue this and its unfair to claim that work is happening when it isnt.
The freebsd port is very old (2.X). Valgrind's internals have been greatly overhauled since then. The NetBSD port tracks the 3.x branch but is stagnanting. However for simple programs the netbsd port is in a usable state. The basic framework is in place but a lot of "wrappers" to syscalls need to be written due to the way Valgrind works..
Member since:
2005-08-17
Member since:
2006-07-26
This tool is amazing. Memory errors suck. I had a case where my program was segfaulting... I go to debug it and just compiling it with -O0 -g to get line numbers and symbols for debugging and the program stopped segfaulting. I tried compiling it the same and resorting to debugging via printf. Just adding a single printf statement and there is no more segfault.
So I knew I had a memory error but no way to debug it.
I actually hacked something up using macros and search/replace of my editor to print out a %P (or whatever prints a pointer address) in every single malloc and calloc. Then before free'ing the pointers I printed out their addresses. Each print statement had a unique number so I could tell where things were being double free'd or malloc'ed but not freed.
I eventually found the problem.
Anyway, it was a hack and I didn't like it. I removed all that debugging code and went on. The next time I had a memory error I looked around and found valgrind. It was so fast and I wished I knew about it the first time though.
It really is a great tool. It will find memory errors that only creep up in rare instances. I have ported programs from Solaris to Linux and Windows. The memory error may show up on one but not the others.
Anyway, as great as a tool that this is... when I start writing a C program, the second I type malloc or calloc, I just say "why bother" and use Java instead.
Yeah, I know there are weird extensions to GCC that allow for array bounds checking and you can use valgrind, but with Java you get that stuff out of the box, complete with a stack trace.
Anyway, I'm rambling and this post is getting long, so I'll just say MERRY CHRISTMAS EVERYBODY!
~Eric
Member since:
2007-12-26