I write C on a non-valgrind capable platform. It's literally scary what you missed when you take what you think is working properly and throw it through valgrind.
I paid severe penalties for memory corruption bugs writing C code in the 80's - penalties in the form of vast time spent debugging in a non-memory protected environment, where a crash could and often would scramble your hard disk.
As a result, I developed a lot of defensive habits to ward off these types of problems, such that I don't make those mistakes very often anymore. But once in a while, I still get weird errors, and the first thing I try is running it under valgrind.
Bing, bang, problem found, fixed. I may be not too far off the mark in saying that valgrind may have saved C and C++.
OS X 10.8 supported... 1 year after 10.8 is released, a few weeks after 10.9 is released. :(
I'm not blaming the authors. The OS X kernel is a moving target. But this does make Valgrind rather useless on OS X. Every time I want to use Valgrind I'm forced to use Linux.
Valgrind's emulation environment wraps syscalls to understand how they read/modify memory. Any time you add a new syscall or change an existing syscall, valgrind needs to be updated. Presumably 10.9 is unsupported due to new/modified syscalls; a basic program using a subset of POSIX standard syscalls may work just fine under valgrind on 10.9.
Apple should probably employ someone full-time to support valgrind on OS X, just for the in-house benefits...
I think we employ all the major Valgrind contributors at Mozilla but they don't work full-time on Valgrind, so that's unfortunate. It is hard to keep up with a moving target where you don't get any advance notice though.
Actually OS X 10.8 only has "limited support" by Valgrind 3.9.0. That was what they said about the previous version of Valgrind as well, but in the latest version the limited support has been "significantly improved".
In any case, several basic features of the previous version of Valgrind work on OSX 10.8/10.9, so I don't think it is correct to say Valgrind is useless on OS X.
It would be more useful if you explained the specific problems with Valgrind on OSX that force you to use Linux.
For what it's worth, I've been using homebrew's valgrind on OS X 10.8 successfully for a while now. I guess the support isn't full (and things like dsym directories are necessary to get debug symbols working correctly) but it's good enough for my purposes.
> Just another reason not to run your development environment on the bleeding edge
If you heavily depend on non-core tools, yes. Otherwise, though, for 99% of developers it was install-reboot-resume work — and the advantages of being able to test what your users use are significant as well.
> Helgrind: False errors resulting from the use of statically initialised mutexes and condition variables have been removed. False errors resulting from the use of pthread_cond_waits that timeout, have been removed.
Awesome. There was no good way to write suppressions for those. I'm glad this got done.
I hear lots of praise for Valgrind. Resorted to it on occasion, but the results were less than stellar. Other than a spew of irrelevant 'leaks' (single-allocations at start that last the life of the program, intentional and not leaks at all) it has, for me, never caught anything important.
Memory corruption errors are hard to find and I'd love a tool that helped me find them. Systematic leaks (app leaks over hours or days) would also be good to find. I've had zero luck with valgrind. Always had to resort to finding them the old-fashioned way.
Somewhat off topic, but I've been learning C through Zed's LCTHW -- and I must say I'm rather impressed at how well it's allowed me to properly learn the concepts involved.
I do wish it was further along though, I haven't seen much change in the month or so I've been working through it :(
Hey, I uploaded the preliminary version of valgrind-freebsd to https://bitbucket.org/stass/valgrind-freebsd/downloads. It seems that there are no regression compared to 3.8.1, but please test, if you can, with your applications and report any errors :)
