[LLVMdev] should asan catch tihs?

[John Criswell]

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>