3 ms·

Another option is AddressSanitizer. Available in GCC and Clang. Compile with -fsanitize=address. http://clang.llvm.org/docs/AddressSanitizer.html http://clang.

Another option is AddressSanitizer. Available in GCC and Clang. Compile with -fsanitize=address. http://clang.llvm.org/docs/AddressSanitizer.html http://clang.llvm.org/docs/AddressSanitizer.html

greglindahl 11y ago
Dr. Memory and Valgrind both work on unaltered binaries -- quite different tools from a compiler option. I expect that AddressSanitizer is quite a bit faster because it's compiled in.
hannob 11y ago
I'm often amazed how many people simply are not aware of address sanitizer. It's orders of magnitude faster than valgrind - and it can find bugs that are simply impossible to find with a runtime-only tool (e.g. most stack oob accesses). However it can't find uninitialized memory (there is msan for that, but that's a bit tricky to set up and not available in gcc).
- Peaker 11y ago
  I think when I tried to use it, it enlarged all my stack allocations. When using precise stack allocations (user threads), it causes all the stacks to blow up.
  - slavik81 11y ago
    It think it uses a lot of extra memory as part of a design a tradeoff that keeps CPU overhead to a minimum. The documentation above mentions the memory cost in the limitations section. By the way, there's a great talk from C++ Going Native 2013, called The Care and Feeding of C++'s Dragons [1] talking about a number new C++ tools, including AddressSanitizer. It's been two years since then, but it's probably still a good introduction. [1] https://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons https://channel9.msdn.com/Events/GoingNative/2013/The-Care-a...
en4bz 11y ago
There's also TSAN for detecting race conditions as well. Personally I've been using valgrind less and less since ASAN and TSAN were released simply because they're so much faster.
- wyldfire 11y ago
  And UBSan for finding undefined behavior.
deleted 11y ago
[deleted]
haldean 11y ago
asan and valgrind are complimentary tools; AddressSanitizer catches memory errors and is fast enough that you can keep it turned on and kind of forget about it, but it doesn't catch leaked memory. Valgrind has been indispensable for leak finding for me, and asan hasn't replaced it.
- slavik81 11y ago
  There is a LeakSanitizer which is enabled by default when you use AddressSanitizer under x86_64 Linux, though it's not supported on other platforms. http://clang.llvm.org/docs/AddressSanitizer.html#memory-leak-detection http://clang.llvm.org/docs/AddressSanitizer.html#memory-leak...
aidenn0 11y ago
While I like -fsanitize=address, the project I spend most of my time on may have tens of thousands of lightweight threads, which makes it a non-starter. Valgrind works fine on it (Albeit at a significant performance impact).
- versteegen 11y ago
  Why is it that valgrind/memcheck can handle that but AddressSanitizer can't?
  - aidenn0 11y ago
    -fsanitize=address adds significant memory overhead on the stack; each thread has its own stack, so this overhead is multiplied by a large number.

Another option is AddressSanitizer. Available in GCC and Clang. Compile with -fsanitize=address. http://clang.llvm.org/docs/AddressSanitizer.html http://clang.llvm.org/docs/AddressSanitizer.html

greglindahl 11y ago

Dr. Memory and Valgrind both work on unaltered binaries -- quite different tools from a compiler option. I expect that AddressSanitizer is quite a bit faster because it's compiled in.

hannob 11y ago

I'm often amazed how many people simply are not aware of address sanitizer. It's orders of magnitude faster than valgrind - and it can find bugs that are simply impossible to find with a runtime-only tool (e.g. most stack oob accesses). However it can't find uninitialized memory (there is msan for that, but that's a bit tricky to set up and not available in gcc).

Peaker 11y ago
I think when I tried to use it, it enlarged all my stack allocations. When using precise stack allocations (user threads), it causes all the stacks to blow up.
- slavik81 11y ago
  It think it uses a lot of extra memory as part of a design a tradeoff that keeps CPU overhead to a minimum. The documentation above mentions the memory cost in the limitations section. By the way, there's a great talk from C++ Going Native 2013, called The Care and Feeding of C++'s Dragons [1] talking about a number new C++ tools, including AddressSanitizer. It's been two years since then, but it's probably still a good introduction. [1] https://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons https://channel9.msdn.com/Events/GoingNative/2013/The-Care-a...

en4bz 11y ago

There's also TSAN for detecting race conditions as well. Personally I've been using valgrind less and less since ASAN and TSAN were released simply because they're so much faster.

wyldfire 11y ago
And UBSan for finding undefined behavior.

deleted 11y ago

[deleted]

haldean 11y ago

asan and valgrind are complimentary tools; AddressSanitizer catches memory errors and is fast enough that you can keep it turned on and kind of forget about it, but it doesn't catch leaked memory. Valgrind has been indispensable for leak finding for me, and asan hasn't replaced it.

slavik81 11y ago
There is a LeakSanitizer which is enabled by default when you use AddressSanitizer under x86_64 Linux, though it's not supported on other platforms. http://clang.llvm.org/docs/AddressSanitizer.html#memory-leak-detection http://clang.llvm.org/docs/AddressSanitizer.html#memory-leak...

aidenn0 11y ago

While I like -fsanitize=address, the project I spend most of my time on may have tens of thousands of lightweight threads, which makes it a non-starter. Valgrind works fine on it (Albeit at a significant performance impact).

versteegen 11y ago
Why is it that valgrind/memcheck can handle that but AddressSanitizer can't?
- aidenn0 11y ago
  -fsanitize=address adds significant memory overhead on the stack; each thread has its own stack, so this overhead is multiplied by a large number.