Address Sanitizer
WWDC 2015 Session 413 (video, PDF):
Address Sanitizer is an LLVM tool for C-based languages, that serves the same purpose as Guard Malloc, as it finds memory errors at runtime, however, it has a lot of benefits over the other tools.
It has much less runtime overhead and it also produces comprehensive, detailed diagnostics that are integrated directly into the Xcode UI.
What’s also very important is that it is the only such tool that works on iOS devices.
The Xcode 7 Address Sanitizer is a revelation. Essential tool.
Address Sanitizer uses a simple but brilliant approach. It reserves a fixed section within the process’s address space called the shadow memory. In Address Sanitizer terms, a byte that is marked as forbidden is “poisoned,” and the shadow memory tracks which bytes are poisoned. A simple formula translates each address within the process’s address space into a spot in the shadow memory. Each eight-byte chunk of regular memory maps to a byte of shadow memory, which tracks the poison state of those eight bytes.
[…]
With this table structure in place, Address Sanitizer generates extra code in the program to check every read and write through a pointer, and throw an error if the memory in question is poisoned. This is the advantage of being integrated into the compiler and not merely existing as an external library or runtime environment: every pointer access can be reliably identified and the appropriate checks added into the machine code.
Compiler integration also allows neat tricks like the ability to poison and guard local and global variables, not just heap allocations. Locals and globals are allocated with a bit of extra padding in between them, and the padding is poisoned to catch any overflows. This is something that Guard Malloc can’t do, and that Valgrind has difficulty with.
It is important to understand that the Address Sanitizer is a run-time tool so you need to exercise your code for it to find problems. This makes it a good candidate to enable when running unit and UI tests. Whilst Apple claims it has low overhead (2x-5x CPU and 2x-3x memory) it is not performance free so you may want to experiment if you have large test suites before leaving it enabled.
