I just tried asan on an optimized 32 bit build of
For performance reasons, asan runs at the end of the optimization
pipeline, so it doesn't check loads which get removed by the IR
optimizers.
-Eli
Also note that this is not the kind of bug for which asan is good.
If we are dereferencing an uninitialized pointer, there is a high chance that the program will SEGV w/o any tool.
If we are unlucky and the garbage is accidentally equal to some valid address, asan will not catch it either.
Valgrind (and work-in-progress MemorySanitizer) will catch this.
–kcc
Kostya, I think you’re misreading the test case. He’s storing a 64-bit value into a 32-bit pointer on a 32-bit platform. The pointer value in f() is initialized (at least in the case where the compiler’s not optimizing away things due to undefined behavior). The problem is that a 64-bit store doesn’t fit into a 32-bit pointer. ASan is catching that when the load isn’t optimized away, and I’ve verified that mainline SAFECode does as well. It also appears that SAFECode finds the error when the noinline attribute is removed, but I think that’s a bug in how we integrated SAFECode into Clang (the store should be optimized away by the LLVM optimizations, but it isn’t). Rafael, for now, if you want to get more pedantic behavior out of ASan and SAFECode, you might want to try reducing the optimization level. However, your test case brings up a good point: should there be an option to clang that makes tools like ASan and SAFECode more or less pedantic (either by reducing optimization or making checks more picky)? It might make a good question at our BoF session next week. 
– John T.
Ah, my bad, I missed ‘&’ in main.
There are quite a few similar cases when asan will miss a bug in fully optimized code, while
it will not miss it at lower opt levels.
–kcc
-fcatch-undefined-behavior (more specifically, -fsanitize=object-size)
already catches this if the function gets inlined:
$ clang -x c++ <(grep -v attribute testcase.cpp) -fsanitize=object-size -m32 -O3
$ ./a.out
<stdin>:4:3: fatal error: store to address 0xff97f8c8 with
insufficient space for an object of type 'uint64_t' (aka 'unsigned
long long')