Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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
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
Original issue reported on code.google.com by
jhietaniemi
on 2 Jun 2014 at 2:06