[llvm-dev] ASAN not finding any bugs? (original) (raw)

Tobias Hieta via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 3 12:01:27 PST 2020

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

-- Tobias

On Mon, Feb 3, 2020, 20:54 Leonard Chan <leonardchan at google.com> wrote:

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.

On Mon, Feb 3, 2020 at 11:47 AM Tobias Hieta via llvm-dev <_ _llvm-dev at lists.llvm.org> wrote:

After experimenting a bit with godbolt it seems like asan is removed from the codegen when the new pass manager is used: https://godbolt.org/z/ccrMiN

But this also seems fixed if you switch to clang 9.0.0. On Mon, Feb 3, 2020 at 8:38 PM Tobias Hieta <tobias at plexapp.com> wrote: > > 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 > > On Mon, Feb 3, 2020 at 5:29 PM Alex Brachet-Mialot > <alexbrachetmialot at gmail.com> wrote: > > > > 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. > > > > On Mon, Feb 3, 2020 at 10:53 AM Tobias Hieta via llvm-dev <_ _llvm-dev at lists.llvm.org> wrote: > >> > >> 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 ASANOPTIONS=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 -fsanitize=address > >> -shared-libasan -fno-omit-frame-pointer -Os -g -Wl,-rpath, >> sanitizers> -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 > >> maxredzone=2048 > >> quarantinesizemb=256M > >> threadlocalquarantinesizekb=1024K > >> malloccontextsize=30 > >> SHADOWSCALE: 3 > >> SHADOWGRANULARITY: 8 > >> SHADOWOFFSET: 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: [ libclangrt.asan-x8664.so] > >> 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] > >> 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] > >> 0x0000000000000001 (NEEDED) Shared library: [libgccs.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 _> >> ________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

LLVM Developers mailing list llvm-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200203/6a1cb638/attachment.html>

More information about the llvm-dev mailing list