-fsanitize=address doesn't detect simple stack access violation

[GoogleCodeExporter]

* What steps will reproduce the problem?

1.  The following code:

int main() {
  char b[100];
  b[100] = 0;
}

compiles (with a warning, which is nice, but imagine that the b[100] is 
something less static and less obvious).

2. clang-mp-3.5 -O1 -g -fsanitize=address -o x x.c

3. Running the executable does nothing (more importantly, doesn't trigger a 
sanitizer fault).

* What is the expected output? What do you see instead?

I expected the sanitizer to trap the error and spit out a failure in runtime.

* What version of the product are you using? On what operating system?

Tried both clang 3.5 (macports in OS X) and clang 3.4 (in ubuntu trusty 14.04, 
64-bit x86), the same (non-)results.

* Please provide any additional information below.

Original issue reported on code.google.com by jhietaniemi on 2 Jun 2014 at 2:06

[GoogleCodeExporter]

More precise versions I tried:

$ clang-mp-3.5 -v
clang version 3.5.0 (trunk 206638)
Target: x86_64-apple-darwin13.2.0
Thread model: posix
$ 

$ clang -v
Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: x86_64-pc-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.2
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
$ 

Original comment by jhietaniemi on 2 Jun 2014 at 2:23

[GoogleCodeExporter]

Your example is too simple -- the compiler optimizes the entire code away. 
Try a bit more realistic example. 

Original comment by konstant...@gmail.com on 2 Jun 2014 at 4:14

• Changed state: Invalid

[GoogleCodeExporter]

Perhaps this deserves a FAQ entry? There are much less trivial cases of this 
(e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60861).

Original comment by tetra2...@gmail.com on 2 Jun 2014 at 6:30

[GoogleCodeExporter]

maybe, maybe not. The problem with our documentation is that it is already too 
long.\
Feel free to add a short Q/A to 
https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#FAQ

Original comment by konstant...@gmail.com on 2 Jun 2014 at 7:49

[GoogleCodeExporter]

I see.  How about this?

#include <stdio.h>
int main() {
  char b[100];
  printf("%d\n", b[100]);
}

This also gets optimized away, but I'd count that "optimizing away" being a 
problem: it hides a genuine problem.

(Yes, if I compile with -O0, I get the expect sanitizer fault.)

Original comment by jhietaniemi on 2 Jun 2014 at 10:36

[GoogleCodeExporter]

I agree that this is a problem, but it's a hard one to solve.
Ideally, ASan should preserve the illusion of operating at the source level, 
i.e. there should not be any difference in the set of reported bugs at 
different optimization levels.

In this case at least there is a warning, so the problem actually was detected 
at compilation time. You could also try UBSan in combination with ASan.

Original comment by euge...@google.com on 2 Jun 2014 at 10:45

[GoogleCodeExporter]

Yeah, sounds like a short entry to the FAQ to the effect:

Why didn't ASan notice an obvious access violation?

One possible reason is that ASan operates at the level of the generated code, 
not at the level of the source code. For example, if your suspect code gets 
optimized away, ASan will not see it.  You could also try UBSan in combination 
with ASan.

Original comment by jhietaniemi on 2 Jun 2014 at 12:08