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...

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.

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...

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.

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.