10 ms·
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, valgrin
by throwaway0094 13y ago
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...
- kenferry 13y agoValgrind is wonderful, but I'm more excited about the Address Sanitizer work going into clang. http://clang.llvm.org/docs/AddressSanitizer.html 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.
- deleted 13y ago[deleted]
- throwaway0094 13y agoAddressSanitizer went into GCC 4.8 recently: http://gcc.gnu.org/gcc-4.8/changes.html http://gcc.gnu.org/gcc-4.8/changes.html
- mrich 13y agoUnfortunately, for large projects I have seen some bugs that currently prevent replacing valgrind with Address Sanitizer.
- pcwalton 13y agoNo. ASan does not detect leaks among other things: http://code.google.com/p/address-sanitizer/wiki/ComparisonOfMemoryTools http://code.google.com/p/address-sanitizer/wiki/ComparisonOf...
- tedmielczarek 13y agoI 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.