[llvm-dev] Using ASAN on C code called from other languages

[Erik de Castro Lopo via llvm-dev]

Thanks for looking at this.

Kostya Serebryany via llvm-dev wrote:

> What does "ghc -Wall -Icsrc -optc "-fsanitize=address" -optc -g -lasan $+
> -o $@" do?

   -Wall         : turns on all warnings
   -Icsrc        : is passed on the the C compiler
   -optc "-fsanitize=address" 
                 : Passes -fsanitize=address to the C compiler
   -optc -g      : Passes -g to the compiler
   -lsan         : is passed on the the linker (also the C compiler).

> I suspect it performs an optimized compilation (e.g. equivalent of clang's
> -O2).
> That would explain why you don't see a bug report:
> the .c code is too simple and the buggy access is optimized away. Take a
> look at the assembly:

Ah, I didn't think of doing that.

> Now, if I insert enough printfs to convince the compiler to keep the buggy
> access, it's still hard for asan to find it,
> because you dereference an element # 2065 of an array of ten elements.
> This simply goes too far from bounds (remember: asan relies on redzones to
> catch buffer overflows).
> 
> If I modify the code like this:
>         printf("ZZZ %p %zd\n", array, sum % 11);
>         array [sum- 2055] = sum ;
> 
> I get a nice
> ==35617== ERROR: AddressSanitizer: stack-buffer-overflow on address
> 0x7ffeccdd9b00 at pc 0x405fcd bp 0x7ffeccdd9a80 sp 0x7ffeccdd9a78
> WRITE of size 8 at 0x7ffeccdd9b00 thread T0

I can get that too now.

It seems that in trying to produce a minimal test case I out-smarted
myself. I will now build the test case up towards my real problem.

Thanks for your help Kostya!

Cheers,
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/