ASAN not finding any bugs?

Project Infrastructure LLVM Dev List Archives
1

Hello,

I am building sanitizers for our different platforms and trying to use
it in an example program, but while it seems like ASAN is running it's
init functions (see stdout below with ASAN_OPTIONS=verbosity=1) it
never catches anything in the program. This is LLVM 8.0.1 btw.

I was using this small test case:

int main(int argc, char** argv) {
  int *array = new int[100];
  delete array;
  return array[argc]; // BOOM
}

I am compiling with:

clang++ -resource-dir <path to sanitizers> -fsanitize=address
-shared-libasan -fno-omit-frame-pointer -Os -g -Wl,-rpath,<path to

-o hello hello.cpp

This is the output from setting verbosity=1 - how can I debug this issue?

==3401806==AddressSanitizer: libc interceptors initialized

`[0x10007fff8000, 0x7fffffffffff]` || HighMem ||
`[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
`[0x00008fff7000, 0x02008fff6fff]` || ShadowGap ||
`[0x00007fff8000, 0x00008fff6fff]` || LowShadow ||
`[0x000000000000, 0x00007fff7fff]` || LowMem ||

MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff
redzone=16
max_redzone=2048
quarantine_size_mb=256M
thread_local_quarantine_size_kb=1024K
malloc_context_size=30
SHADOW_SCALE: 3
SHADOW_GRANULARITY: 8
SHADOW_OFFSET: 0x7fff8000
==3401806==Installed the sigaction for signal 11
==3401806==Installed the sigaction for signal 7
==3401806==Installed the sigaction for signal 8
==3401806==T0: stack [0x7fff3bf5c000,0x7fff3c75c000) size 0x800000;
local=0x7fff3c759244
==3401806==AddressSanitizer Init done

➜ readelf -d hello

Dynamic section at offset 0xe18 contains 25 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libclang_rt.asan-x86_64.so]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000c (INIT) 0x400570
0x000000000000000d (FINI) 0x4007b8
0x0000000000000004 (HASH) 0x400278
0x0000000000000005 (STRTAB) 0x400318
0x0000000000000006 (SYMTAB) 0x4002a0
0x000000000000000a (STRSZ) 462 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000015 (DEBUG) 0x0
0x0000000000000003 (PLTGOT) 0x601000
0x0000000000000002 (PLTRELSZ) 72 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x400528
0x0000000000000007 (RELA) 0x400510
0x0000000000000008 (RELASZ) 24 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffffe (VERNEED) 0x4004f0
0x000000006fffffff (VERNEEDNUM) 1
0x000000006ffffff0 (VERSYM) 0x4004e6
0x0000000000000000 (NULL) 0x0

2

I haven’t looked at the code gen yet because I’m not on my computer right now but I suspect that at -Os the compiler is optimizing this away because it knows it to be undefined behavior. Try with -O0.

3

Hello Alex,

Thanks for the hint. It was actually not the -O flag that created the
problem. But it pointed me in the right direction, when I passed
-fno-experimental-new-pass-manager it started to show the error. My
guess is that the new pass manager is more aggressive in removing UB?

Thanks,
Tobias

4

After experimenting a bit with godbolt it seems like asan is removed
from the codegen when the new pass manager is used:

But this also seems fixed if you switch to clang 9.0.0.

5

I believe this is just because asan wasn’t ported into the new PM until the clang 9 release which is why there’s no asan instrumentation when using the new PM for older releases.

6

Thanks for the explanation! I will turn off the new PM for clang 8 or earlier.

– Tobias