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 11/3/12 4:06 AM, Kostya Serebryany wrote:> 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.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.> > --kcc > > On Sat, Nov 3, 2012 at 5:38 AM, Eli Friedman <eli.friedman at gmail.com > <mailto:eli.friedman at gmail.com>> wrote: > > On Fri, Nov 2, 2012 at 6:27 PM, Rafael Espíndola > <rafael.espindola at gmail.com <mailto: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 <mailto:LLVMdev at cs.uiuc.edu> > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > _______________________________________________ > 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/ea6f3561/attachment.html>
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 On Sat, Nov 3, 2012 at 5:22 PM, John Criswell <criswell at illinois.edu> wrote:> On 11/3/12 4:06 AM, Kostya Serebryany wrote: > > 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. > > > 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. > > > > > --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 >> > > > > _______________________________________________ > LLVM Developers mailing listLLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121103/4a1dccbc/attachment.html>