Valgrind Release 3.9.0(valgrind.org)
valgrind.org
Valgrind Release 3.9.0
http://valgrind.org/docs/manual/dist.news.html
6 comments
Valgrind is a truly awesome product. It has saved me countless hours tracking down weird memory corruption errors.
Absolutely. Valgrind is the holy grail of C/CPP programming.
Definitely.
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 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.
A good discipline also helps. ;)
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++.
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.
Maybe someone from apple needs to make sure that newly supported kernels work on valgrind?
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...
Apple should probably employ someone full-time to support valgrind on OS X, just for the in-house benefits...
Valgrind is wonderful, but I'm more excited about the Address Sanitizer work going into clang.
http://clang.llvm.org/docs/AddressSanitizer.html
It catches more stuff than valgrind, and only slows a program down to ~half normal speed.
It requires compile time instrumentation, but I'm usually ok with that.
http://clang.llvm.org/docs/AddressSanitizer.html
It catches more stuff than valgrind, and only slows a program down to ~half normal speed.
It requires compile time instrumentation, but I'm usually ok with that.
AddressSanitizer went into GCC 4.8 recently: http://gcc.gnu.org/gcc-4.8/changes.html
No. ASan does not detect leaks among other things: http://code.google.com/p/address-sanitizer/wiki/ComparisonOf...
[deleted]
Unfortunately, for large projects I have seen some bugs that currently prevent replacing valgrind with Address Sanitizer.
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.
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.
Why don't you use XCode's profiling tools? They are quite comprehensive and XCode is free.
Just another reason not to run your development environment on the bleeding edge
Just another reason not to run your development environment on a Mac
Please send you Mac my way! Because there is also no good development environment outside OSX. But we've had this discussion...
Customers often require bleeding edge support, often so they can use features present in the new OS.
> 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.
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.
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.
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.
Use --show-possibly-lost=no to avoid those "possibly lost" reports.
can someone suggest me a good tutorial for Valgrind? Thank you
Zed Shaw's Learn C The Hard Way [1] makes extensive use of Valgrind, with a nice crash course in [2]
[1] http://c.learncodethehardway.org/book/
[2] http://c.learncodethehardway.org/book/ex4.html
[1] http://c.learncodethehardway.org/book/
[2] http://c.learncodethehardway.org/book/ex4.html
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 :(
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 :(
The official Quick Start Guide [0] is decent I think. Do you need something specific?
[0] - http://valgrind.org/docs/manual/QuickStart.html
[0] - http://valgrind.org/docs/manual/QuickStart.html
No FreeBSD support mentioned :-(
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 :)
I'll try to get the valgrind-freebsd updated some time this week. So it's coming.