I just tried asan on an optimized 32 bit build of
-------------------------------------
#include <stdint.h>
__attribute__((noinline))
void f(uint64_t *p) {
*p = 42;
}
int main() {
void *p;
f((uint64_t*)&p);
}
------------------------------------
and it correctly catches the invalid access. If I comment the
attribute, the optimizers find and exploit the undefined behavior and
asan fails to report it. Is this the expected behavior? Is this
something that needs -fcatch-undefined-behavior instead?
Cheers,
Rafael
On Fri, Nov 2, 2012 at 6:27 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:> I just tried asan on an optimized 32 bit build of > ------------------------------------- > #include <stdint.h> > __attribute__((noinline)) > void f(uint64_t *p) { > *p = 42; > } > int main() { > void *p; > f((uint64_t*)&p); > } > ------------------------------------ > > and it correctly catches the invalid access. If I comment the > attribute, the optimizers find and exploit the undefined behavior and > asan fails to report it. Is this the expected behavior? Is this > something that needs -fcatch-undefined-behavior instead?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 On Sat, Nov 3, 2012 at 5:38 AM, Eli Friedman <eli.friedman at gmail.com> wrote:> On Fri, Nov 2, 2012 at 6:27 PM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: > > I just tried asan on an optimized 32 bit build of > > ------------------------------------- > > #include <stdint.h> > > __attribute__((noinline)) > > void f(uint64_t *p) { > > *p = 42; > > } > > int main() { > > void *p; > > f((uint64_t*)&p); > > } > > ------------------------------------ > > > > and it correctly catches the invalid access. If I comment the > > attribute, the optimizers find and exploit the undefined behavior and > > asan fails to report it. Is this the expected behavior? Is this > > something that needs -fcatch-undefined-behavior instead? > > 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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121103/8056b3cd/attachment.html>
On Fri, Nov 2, 2012 at 6:27 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:> I just tried asan on an optimized 32 bit build of > ------------------------------------- > #include <stdint.h> > __attribute__((noinline)) > void f(uint64_t *p) { > *p = 42; > } > int main() { > void *p; > f((uint64_t*)&p); > } > ------------------------------------ > > and it correctly catches the invalid access. If I comment the > attribute, the optimizers find and exploit the undefined behavior and > asan fails to report it. Is this the expected behavior? Is this > something that needs -fcatch-undefined-behavior instead?-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')