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.
Valgrind 3.3.0 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Valgrind is a great tool and any speed increases (and above all good error messages) are most welcome.
Yes, Valgrind was already a amazing tool to show all about your program memory (consumption, leaks, …). It already helped me really often and … it is so easy to use !
Thanks to the Valgrind team.
Valgrind has helped me a lot with my foolish errors.
Thanks guys.
Helgrind is back! Too bad I needed it for my last project, a half year ago.
I agree, Valgrind is a wonderful tool that all programmers should use. The only downside is that it’s Linux only; that means I can’t use it on my NetBSD box.
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
Right; the FreeBSD port, I believe, is much further along than the NetBSD port. The NetBSD port was/is on hold the last time I checked.
I guess I _could_ try it out though. Worth a try.
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..
I like valgrind
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
I like it, too