[llvm-dev] ASAN not finding any bugs?

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 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
>> > >> 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
>> > >> 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
>> > >> _______________________________________________
>> > >> 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>