[LLVMdev] should asan catch tihs?

[Kostya Serebryany]

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>