[LLVMdev] should asan catch tihs?

[Kostya Serebryany]

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>