AddressSanitizer, ThreadSanitizer, MemorySanitizer

Related tags

Utilities sanitizers
Overview

sanitizers

This project is the home for Sanitizers: AddressSanitizer, MemorySanitizer, ThreadSanitizer, LeakSanitizer, and more The actual code resides in the LLVM repository. Here we keep extended documentation, bugfixes and some helper code.

The documentation for our tools:

  • AddressSanitizer (detects addressability issues) and LeakSanitizer (detects memory leaks)
  • ThreadSanitizer (detects data races and deadlocks) for C++ and Go
  • MemorySanitizer (detects use of uninitialized memory)
  • HWASAN, or Hardware-assisted AddressSanitizer, a newer variant of AddressSanitizer that consumes much less memory
  • UBSan, or UndefinedBehaviorSanitizer

Some of the sanitizers are also available for different OS Kernels:

Issues
  • tsan address space mapping on NetBSD/amd64 with ASLR

    tsan address space mapping on NetBSD/amd64 with ASLR

    Hello,

    I'm trying to add NetBSD process map in tsan (lib/tsan/rtl/tsan_platform.h).

    There is ASLR for user-space process map enforced.

    The stack grows downards and has preserved layout for 128GB of RAM. With a memory gap under the stack there is heap that is being allocated top-down.

    ld.elf_so maps libraries with mmap(2) on the heap.

    struct Mapping {
      static const uptr kLoAppMemBeg   = 0x000000000000ull;
      static const uptr kLoAppMemEnd   = 0x300000000000ull;
    
      static const uptr kShadowBeg     = ;
      static const uptr kShadowEnd     = ;
    
      static const uptr kMetaShadowBeg = ;
      static const uptr kMetaShadowEnd = ;
    
      static const uptr kTraceMemBeg   = ;
      static const uptr kTraceMemEnd   = ;
    
      static const uptr kHeapMemBeg    = 0x600000000000ull;
      static const uptr kHeapMemEnd    = 0x7e0000000000ull;
    
      static const uptr kHiAppMemBeg   = 0x7e0000000000ull;
      static const uptr kHiAppMemEnd   = 0x7f7ffffff000ull;
    
      static const uptr kAppMemMsk     = ;
      static const uptr kAppMemXor     = ;
    };
    

    Is it possible to add shadow, metashadow, trace and appmem mask/xor for so wide address space?

    opened by krytarowski 52
  • support swapcontext

    support swapcontext

    Originally reported on Google Code with ID 189

    AddressSanitizer does not fully support swapcontext. 
    Sometimes, swapcontext causes the entire shadow region (16T) 
    to be written by asan-internal routines (e.g. __asan_handle_no_return)
    because the location of the stack changes w/o asan noticing it.
    This may cause the machine to die or hang for a long time. 
    
    I am not at all sure if asan can fully support swapcontext, 
    but we at least should collect more test cases. 
    

    Reported by konstantin.s.serebryany on 2013-05-22 07:40:59

    Type-Defect Priority-Medium ProjectAddressSanitizer Status-Accepted 
    opened by ramosian-glider 43
  • Unable to run sanitized executables on ppc64le Ubuntu and SLES

    Unable to run sanitized executables on ppc64le Ubuntu and SLES

    all executables built with asan fail to start on ppc64le machines.

    simplest program to reproduce:

    int main(int, char**) {
      return 0;
    }
    

    build: gcc-5 -fsanitize=address main.cpp -o test

    run:

    [email protected]:~/asan-test$ ASAN_OPTIONS="debug=1:verbosity=3" ./test 
    ==24573==Parsed ASAN_OPTIONS: debug=1:verbosity=3
    ==24573==AddressSanitizer: failed to intercept '__isoc99_printf'
    ==24573==AddressSanitizer: failed to intercept '__isoc99_sprintf'
    ==24573==AddressSanitizer: failed to intercept '__isoc99_snprintf'
    ==24573==AddressSanitizer: failed to intercept '__isoc99_fprintf'
    ==24573==AddressSanitizer: failed to intercept '__isoc99_vprintf'
    ==24573==AddressSanitizer: failed to intercept '__isoc99_vsprintf'
    ==24573==AddressSanitizer: failed to intercept '__isoc99_vsnprintf'
    ==24573==AddressSanitizer: failed to intercept '__isoc99_vfprintf'
    ==24573==AddressSanitizer: failed to intercept '__cxa_throw'
    ==24573==AddressSanitizer: libc interceptors initialized
    || `[0x120000000000, 0x7fffffffffff]` || HighMem    ||
    || `[0x044000000000, 0x11ffffffffff]` || HighShadow ||
    || `[0x024000000000, 0x043fffffffff]` || ShadowGap  ||
    || `[0x020000000000, 0x023fffffffff]` || LowShadow  ||
    || `[0x000000000000, 0x01ffffffffff]` || LowMem     || 
    MemToShadow(shadow): 0x024000000000 0x0247ffffffff 0x028800000000 0x043fffffffff
    redzone=16 
    max_redzone=2048
    quarantine_size=256M
    malloc_context_size=30
    SHADOW_SCALE: 3
    SHADOW_GRANULARITY: 8
    SHADOW_OFFSET: 20000000000
    ==24573==Installed the sigaction for signal 11
    ==24573==AddressSanitizer CHECK failed: ../../../../libsanitizer/asan/asan_poisoning.cc:24 " ((AddrIsInMem(addr))) != (0)" (0x0, 0x0)
       <empty stack>
    

    environments tested:

    1. SUSE Linux Enterprise Server 12 SP3 (Linux linux 4.4.120-94.17-default #1 SMP Wed Mar 14 17:23:00 UTC 2018 (cf3a7bb) ppc64le ppc64le ppc64le GNU/Linux)
    2. Ubuntu 16.04.3 LTS (Linux ci-agent 4.13.0-16-generic #19~16.04.3-Ubuntu SMP Mon Oct 16 18:58:28 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux)

    compilers tested: gcc-5, gcc-6, gcc-7

    opened by diameter 30
  • ASan needs to keep track of all the libraries loaded during the process lifetime

    ASan needs to keep track of all the libraries loaded during the process lifetime

    Originally reported on Google Code with ID 89

    In the following situation:
    
    > malloc or free gets calls from xyz.dylib
    > xyz.dylib gets unloaded 
    > a bug happens and we want to report the stack trace of malloc/free which has xyz.dylib
    in it. 
    
    we need to restore the library layout at the stack collection time in order to symbolize
    it correctly.
    
    Possible solution:
    
    > We keep an epoch counter that is incremented for each dlopen and 
    > dlclose (we also write down the [un]loaded library and the slide value 
    > each time we do that). For each stack we just sacrifice one frame to 
    > keep the corresponding counter. When symbolizing, it's easy to replay 
    > the sequence of dlopen/dlclose events and find out which libraries 
    > were loaded.
    
    

    Reported by ramosian.glider on 2012-07-18 09:21:08

    Priority-Medium ProjectAddressSanitizer Type-Enhancement Status-New 
    opened by ramosian-glider 30
  • Could threadSanitizer be used with static linked lib

    Could threadSanitizer be used with static linked lib

    An old project which is linked with some xx.a file, can I add thead sanitizer to this project? When I did so, a lot of undefined referenced __tsan_func_entry printed. What should I do?

    opened by 0chunhui 29
  • Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

    Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

    On x86_64-apple-darwin10.8 I get several hundred asan failures with 6.0 (see https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg01013.html). Most (if not all) of them are of the kind

    dyld: Symbol not found: _dyldVersionNumber Referenced from: /opt/gcc/build_c/x86_64-apple-darwin10.8.0/i386/libsanitizer/asan/.libs/libasan.3.dylib Expected in: flat namespace in /opt/gcc/build_c/x86_64-apple-darwin10.8.0/i386/libsanitizer/asan/.libs/libasan.3.dylib

    AFAICT they are related to revision r229111

    +bool DyldNeedsEnvVariable() {

    • // If running on OS X 10.11+ or iOS 9.0+, dyld will interpose even if
    • // DYLD_INSERT_LIBRARIES is not set. However, checking OS version via
    • // GetMacosVersion() doesn't work for the simulator. Let's instead check
    • // dyldVersionNumber, which is exported by dyld, against a known version
    • // number from the first OS release where this appeared.
    • return dyldVersionNumber < kMinDyldVersionWithAutoInterposition; +}
    opened by DominiquedHumieres 28
  • ASan doesn't work in 32bit armeabi-v7a on pixel

    ASan doesn't work in 32bit armeabi-v7a on pixel

    Even for a simple "Hello world" app, usage of libclang_rt.asan-arm-android.so on a Pixel running an armeabi-v7a abi app will result in: ==5512==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.

    Same project reconfigured for 64bit mode works flawlessly.

    https://github.com/google/sanitizers/wiki/AddressSanitizer seems to indicate that 32bit arm should be working. Lemme know if you need an example project.

    opened by gpx1000 26
  • Missing coverage instrumentation with trace-pc-guard option

    Missing coverage instrumentation with trace-pc-guard option

    While trying to get a coverage for sanitizers for my library compiled with Clang 5.0.0 I have encountered a problem that some calls to __sanitizer_coverage_trace_pc_guards are missing in several basic blocks. I made a reduced reprocase for this and built it with -gline-tables-only -O0 -fsanitize=address -fsanitize-coverage=trace-pc-guard flags:

    clang -gline-tables-only -O0 -fsanitize=address -fsanitize-coverage=trace-pc-guard -S reduced.c

    extern void clobber1(int *state_ptr);
    extern void clobber2(int *state_ptr);
    extern void clobber3(int *state_ptr);
    
    int foo(char c, int state, int threshold) {
       while (state < threshold) {
         switch (state) {
         case 1:
           clobber1(&state);
           if (c == '*') {
             state++;
           } else if (c == '/') {
             state--;                 <============== missing __sanitizer_cov_trace_pc_guard call
           } else {
             clobber1(&state);
             goto out;
           }
           clobber2(&state);
           break;
         case 2:
           clobber3(&state);
           break;
         }
       }
    out:
       return state;
    }
    
    int main(int argc, char **argv) {
       return foo(argv[1][2], argc + 4, 255) > 100;
    }
    

    After examination of dumped LLVM IR (-print-after-all) I have found that there are no calls of __sanitizer_coverage_trace_pc_guard in if.then6 basic block that corresponds to else if (c == '/') fall through case:

    sw.bb:                                            ; preds = %while.body
       call void @clobber1(i32* %state.addr), !dbg !15
       %3 = load i8, i8* %c.addr, align 1, !dbg !16
       %conv = sext i8 %3 to i32, !dbg !16
       %cmp1 = icmp eq i32 %conv, 42, !dbg !17
       br i1 %cmp1, label %if.then, label %if.else, !dbg !16
    
    if.then:                                          ; preds = %sw.bb
       call void @__sanitizer_cov_trace_pc_guard(i32* inttoptr (i64 add (i64 ptrtoint ([6 x i32]* @__sancov_gen_ to i64), i64 8) to i32*)), !dbg !18
       call void asm sideeffect "", ""(), !dbg !18
       %4 = load i32, i32* %state.addr, align 4, !dbg !18
       %inc = add nsw i32 %4, 1, !dbg !18
       store i32 %inc, i32* %state.addr, align 4, !dbg !18
       br label %if.end8, !dbg !19
    
    if.else:                                          ; preds = %sw.bb
       %5 = load i8, i8* %c.addr, align 1, !dbg !20
       %conv3 = sext i8 %5 to i32, !dbg !20
       %cmp4 = icmp eq i32 %conv3, 47, !dbg !21
       br i1 %cmp4, label %if.then6, label %if.else7, !dbg !20
    
    if.then6:                                         ; preds = %if.else       <======= no __sanitizer_cov_trace_pc_guard
       %6 = load i32, i32* %state.addr, align 4, !dbg !22
       %dec = add nsw i32 %6, -1, !dbg !22
       store i32 %dec, i32* %state.addr, align 4, !dbg !22
       br label %if.end, !dbg !23
    
    if.else7:                                         ; preds = %if.else
       call void @__sanitizer_cov_trace_pc_guard(i32* inttoptr (i64 add (i64 ptrtoint ([6 x i32]* @__sancov_gen_ to i64), i64 12) to i32*)), !dbg !24
       call void asm sideeffect "", ""(), !dbg !24
       call void @clobber1(i32* %state.addr), !dbg !24
       br label %out, !dbg !25
    
    if.end:                                           ; preds = %if.then6
       br label %if.end8
    
    if.end8:                                          ; preds = %if.end, %if.then
       call void @clobber2(i32* %state.addr), !dbg !26
       br label %sw.epilog, !dbg !27
    

    But, if I remove the goto out instruction, then __sanitizer_cov_trace_pc_guard call appears in all if clauses as expected.

    I also reported this issue to [email protected] but haven't got any reply yet: http://lists.llvm.org/pipermail/llvm-dev/2017-March/111209.html

    opened by nikdmt 26
  • ASAN on Windows completely broken since clang 3.8.0

    ASAN on Windows completely broken since clang 3.8.0

    If one tries ASAN on Windows with a basic sample and Clang 3.7.1 it seems to work.

    But on Clang 3.8.0 even the most basic example:

    int
    main(int argc, char *argv[])
    {
       return 0;
    }
    

    fails with:

    no_op.exe caused an Access Violation at location 6B392FDD in module clang_rt.asan_dynamic-i386.dll Writing to location 00000000.
    
    Registers:
    eax=00000001 ebx=6b3eb7ab ecx=6b3eb7ab edx=00000000 esi=6b428cd0 edi=00000000
    eip=6b392fdd esp=002dee94 ebp=002deed0 iopl=0         nv up ei ng nz ac po cy
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010297
    
    AddrPC   Params
    6B392FDD 6B3EB7AB 002DEF18 6B3C3F34  clang_rt.asan_dynamic-i386.dll!0x2fdd
    6B3940B4 6B3EB7AB 00000000 00004000  clang_rt.asan_dynamic-i386.dll!__sanitizer_set_report_path
    6B3C3F34 65109FD8 00000080 005AE560  clang_rt.asan_dynamic-i386.dll!__asan_storeN_noabort
    6B3AAA89 000003BC 00000008 002DEFB8  clang_rt.asan_dynamic-i386.dll!__ubsan_handle_cfi_bad_icall_abort
    6B3AB3FE 00000001 000003BC 002DEFB8  clang_rt.asan_dynamic-i386.dll!__ubsan_handle_cfi_bad_icall_abort
    6B3BC4EB 00000001 000003BC 00000000  clang_rt.asan_dynamic-i386.dll!__asan_wrap_atol
    6B3CB7AF 00000001 000003BC 00000001  clang_rt.asan_dynamic-i386.dll!__ubsan_handle_cfi_bad_type_abort
    6B3CB150 6B390000 00000001 002DF78C  clang_rt.asan_dynamic-i386.dll!__ubsan_handle_cfi_bad_type_abort
    6B3CA945 6B390000 00000001 002DF78C  clang_rt.asan_dynamic-i386.dll!__ubsan_handle_cfi_bad_type_abort
    6B3CA8E4 6B390000 00000001 002DF78C  clang_rt.asan_dynamic-i386.dll!__ubsan_handle_cfi_bad_type_abort
    76F192E0 6B3CA8C8 6B390000 00000001  [email protected]
    76F2061B 002DF78C 7EFDD000 7EFDE000  [email protected]
    76F26D84 002DF78C 76EE0000 159B2E85  [email protected]
    76F2583E 002DF78C 76EE0000 00000000  [email protected]
    76F19809 002DF78C 76EE0000 00000000  [email protected]
    

    Ditto for Clang from LLVM-3.9.0-r268238-win32.exe downloaded today.

    The crash happens when loading clang_rt.asan_dynamic-i386.dll , even before main function is reached.

    opened by jrfonseca 25
  • ThreadSanitizer with GCC 4.9.0 - TSAN_OPTIONS ignored

    ThreadSanitizer with GCC 4.9.0 - TSAN_OPTIONS ignored

    Originally reported on Google Code with ID 95

    I am using ThreadSanitizer on a 'C' program compiled with GCC 4.9.0 running under Ubuntu
    2.04.
    
    ThreadSanitizer itself is working properly, but it is ignoring the TSAN_OPTIONS environment
    variable.
    
    This issue occurs whether I am running the program from within GDB 7.4. or directly
    from the command line.
    
    I have set the environment variable from the command line before running GDB as follows:
    
    export TSAN_OPTIONS=report_bugs=0
    
    I have confirmed that TSAN_OPTIONS is set as expected, both from "printenv" on the
    command line and also from within the "C" program under test, using getenv().
    
    For example the above setting, which should stop bugs from being reported by ThreadSanitizer,
    fails to stop bugs being reported by ThreadSanitizer.
    
    Some other switches I have tested are suppressions and log_path.
    
    TSAN Compile switches are -fsanitize=thread -fno-omit-frame-pointer -fPIE
    
    TSAN Link switches -fsanitize=thread -fno-omit-frame-pointer -pie
    
    Any help or ideas are appreciated.
    
    
    

    Reported by gblaneyToronto on 2015-08-18 09:57:10

    Type-Defect Priority-Medium Status-Fixed ProjectThreadSanitizer 
    opened by ramosian-glider 25
  • No filename when using llvm-symbolizer with ASan on Mac

    No filename when using llvm-symbolizer with ASan on Mac

    Originally reported on Google Code with ID 207

    What steps will reproduce the problem?
    1. Build Firefox using the MOZCONFIG=~/mozconfig-asan (attached)
    2. Trip https://bugzilla.mozilla.org/show_bug.cgi?id=887499
    
    What is the expected output? What do you see instead?
    
    With ASAN_SYMBOLIZER_PATH=~/llvm/build/Release+Asserts/bin/llvm-symbolizer, all lines
    are missing source filenames and line numbers:
    
        #0 0x1057ac304 in nsINode::ReplaceOrInsertBefore(bool, nsINode*, nsINode*, mozilla::ErrorResult&)
    (/Users/jruderman/trees/mozilla-central/obj-firefox-asan/dist/Nightly.app/Contents/MacOS/XUL+0x1577304)
    
    With | ~/llvm/projects/compiler-rt/lib/asan/scripts/asan_symbolize.py, all lines have
    source filenames and line numbers:
    
        #0 0x1057a7304 in nsINode::ReplaceOrInsertBefore nsINode.cpp:1616
    
    What version of the product are you using? On what operating system?
    
    * LLVM r185346
    * Mac 10.7.5
    * Firefox: https://hg.mozilla.org/mozilla-central/rev/4ffb23062b3b
    
    Please provide any additional information below.
    
    
    

    Reported by jruderman on 2013-07-02 03:16:31


    - _Attachment: [mozconfig-asan](https://storage.googleapis.com/google-code-attachments/address-sanitizer/issue-207/comment-0/mozconfig-asan)_ Type-Defect Priority-Medium ProjectAddressSanitizer OpSys-OSX Status-Done 
    opened by ramosian-glider 25
  • Leak detection failed if link with SDL2

    Leak detection failed if link with SDL2

    Hi folks, recently I've been learning to use SDL2 to display image or playback audio. The following simple SDL2 code failed when LSan in on: // empty_window.cpp

    #if defined(__cplusplus)
    extern "C" {
    #endif
    
    #include <SDL.h>
    
    #if defined(__cplusplus)
    };
    #endif
    
    int main(int argc, char *argv[]) {
        int quit = 0;
        SDL_Event event;
    
        SDL_Init(SDL_INIT_VIDEO);
    
        SDL_Window *screen = SDL_CreateWindow("My SDL Empty window",
                                              SDL_WINDOWPOS_UNDEFINED,
                                              SDL_WINDOWPOS_UNDEFINED,
                                              640, 480, 0);
        for (; !quit;) {
            SDL_WaitEvent(&event);
    
            switch (event.type) {
            case SDL_QUIT: {
                quit = 1;
                break;
            }
            }
        }
    
        SDL_Quit();
        return 0;
    }
    
    企业微信截图_9dd60bc2-3b04-456f-91be-93505eb46071

    I am sure that this simple code has no any memory leak, but lsan detected.

    so it is a lsan bug ? or SDL2 has memory leak ? or I using lsan in the wrong way?

    opened by jiemojiemo 1
  • Data race of std::atomic<std::shared_ptr<T>>(or std::atomic<std::weak_ptr<T>>) in gcc 12.1

    Data race of std::atomic>(or std::atomic>) in gcc 12.1

    Hi! First, thank you for all your contributions to open source society.

    In Ubuntu 22.04(and 22.10) with gcc 12.1, TSan is reporting a data race for std::atomic<std::shared_ptr<T>>(or std::atomic<std::weak_ptr<T>>). The code snippet for the reproduction of the issue is following:

    #include <atomic>
    #include <iostream>
    #include <memory>
    #include <thread>
    
    int main() {
            using test_type = std::shared_ptr<int>;
            std::atomic<test_type> value;
    
            auto worker = std::jthread(
                    [&value] (std::stop_token token) {
                            while (!token.stop_requested()) { // to prevent the thread from finishing too quickly
                                    value.store(test_type{}, std::memory_order_release);
                            }
                    }
            );
    
            std::cout << value.load(std::memory_order_acquire) << '\n';
    
            return 0;
    }
    

    The access to the atomic variable is using the acquire-release semantic. But when I compile the source with g++-12 -std=c++20 -g -O0 -fsanitize=thread -o reproducer reproducer.cpp and run it, TSan reports the following warning:

    ==================
    WARNING: ThreadSanitizer: data race (pid=1399)
      Write of size 8 at 0x7ffdcaf939b0 by thread T1:
        #0 std::enable_if<std::__and_<std::__not_<std::__is_tuple_like<int*> >, std::is_move_constructible<int*>, std::is_move_assignable<int*> >::value, void>::type std::swap<int*>(int*&, int*&) /usr/include/c++/12/bits/move.h:205 (reproducer+0x4db7)
        #1 std::_Sp_atomic<std::shared_ptr<int> >::swap(std::shared_ptr<int>&, std::memory_order) /usr/include/c++/12/bits/shared_ptr_atomic.h:510 (reproducer+0x496c)
        #2 std::atomic<std::shared_ptr<int> >::store(std::shared_ptr<int>, std::memory_order) /usr/include/c++/12/bits/shared_ptr_atomic.h:597 (reproducer+0x47fa)
        #3 operator() /home/demian51/playground/reproducer.cpp:13 (reproducer+0x25ca)
        #4 __invoke_impl<void, main()::<lambda(std::stop_token)>, std::stop_token> /usr/include/c++/12/bits/invoke.h:61 (reproducer+0x2fe7)
        #5 __invoke<main()::<lambda(std::stop_token)>, std::stop_token> /usr/include/c++/12/bits/invoke.h:96 (reproducer+0x2f3c)
        #6 _M_invoke<0, 1> /usr/include/c++/12/bits/std_thread.h:252 (reproducer+0x2e48)
        #7 operator() /usr/include/c++/12/bits/std_thread.h:259 (reproducer+0x2dd4)
        #8 _M_run /usr/include/c++/12/bits/std_thread.h:210 (reproducer+0x2d8a)
        #9 <null> <null> (libstdc++.so.6+0xdc2e2)
    
      Previous read of size 8 at 0x7ffdcaf939b0 by main thread:
        #0 std::_Sp_atomic<std::shared_ptr<int> >::load(std::memory_order) const /usr/include/c++/12/bits/shared_ptr_atomic.h:500 (reproducer+0x4a5d)
        #1 std::atomic<std::shared_ptr<int> >::load(std::memory_order) const /usr/include/c++/12/bits/shared_ptr_atomic.h:589 (reproducer+0x484b)
        #2 main /home/demian51/playground/reproducer.cpp:18 (reproducer+0x269c)
    
      Location is stack of main thread.
    
      Location is global '<null>' at 0x000000000000 ([stack]+0x1f9b0)
    
      Thread T1 (tid=1401, running) created by main thread at:
        #0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001 (libtsan.so.2+0x63a69)
        #1 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) <null> (libstdc++.so.6+0xdc3b8)
        #2 _S_create<main()::<lambda(std::stop_token)> > /usr/include/c++/12/thread:232 (reproducer+0x286e)
        #3 jthread<main()::<lambda(std::stop_token)> > /usr/include/c++/12/thread:128 (reproducer+0x27ad)
        #4 main /home/demian51/playground/reproducer.cpp:16 (reproducer+0x2684)
    
    SUMMARY: ThreadSanitizer: data race /usr/include/c++/12/bits/move.h:205 in std::enable_if<std::__and_<std::__not_<std::__is_tuple_like<int*> >, std::is_move_constructible<int*>, std::is_move_assignable<int*> >::value, void>::type std::swap<int*>(int*&, int*&)
    ==================
    ThreadSanitizer: reported 1 warnings
    

    The result of running g++-12 -v is:

    Using built-in specs.
    COLLECT_GCC=g++-12
    COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
    OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
    OFFLOAD_TARGET_DEFAULT=1
    Target: x86_64-linux-gnu
    Configured with: ../src/configure -v --with-pkgversion='Ubuntu 12.1.0-5ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-NVfNST/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-NVfNST/gcc-12-12.1.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
    Thread model: posix
    Supported LTO compression algorithms: zlib zstd
    gcc version 12.1.0 (Ubuntu 12.1.0-5ubuntu1)
    

    The warning disappears when I change the test_type to int or int*. So I digged the implementation of std::atomic<std::shared_ptr<T>> in libstdc++, but everything was looking good. Specialization of std::atomic<std::shared_ptr> is implemented by using __atomic_base as spinlock, which is implementation of std::atomic in libstdc++, which already works well with TSan. https://github.com/gcc-mirror/gcc/blob/releases/gcc-12.1.0/libstdc++-v3/include/bits/shared_ptr_atomic.h

    I'm not sure which one is the culprit. TSan, libstdc++, or my code? Please let me know.

    opened by demian51 3
  • Clarify official support of ASAN-DSO

    Clarify official support of ASAN-DSO

    On https://github.com/google/sanitizers/wiki/AddressSanitizerAsDso it says

    The GCC variant of ASAN offers both static and DSO variants and DSO is the default.

    ASAN-DSO is not (yet?) officially supported.

    This says that at the same time, it's the default but not officially supported. This looks like a contradiction.

    Also, what does "yet?" mean? Since this is the official wiki of the official project, why is this a question?

    It would be great if the page could clear up some confusion; apparently it was last edited in 2015 so maybe it is very out-of-date.

    opened by nh2 0
  • attribute no_sanitize_address not work

    attribute no_sanitize_address not work

    I'm using 9.3.0 compile my project, for some functions I add attribute((no_sanitize_address)) to avoid, but 'AddressSanitizer: memcpy-param-overlap' error not disapper

    I write a demo to test, It works well

    here is my flags: BUILD_FLAGS: -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D_NO_EXCEPTION -g -Wall -Wextra -Wunused-parameter -Wformat -Wconversion -Wno-invalid-offsetof -Wno-deprecated -fno-strict-aliasing -fno-omit-frame-pointer -mtune=generic -Wno-psabi -Wno-sign-compare -Wno-class-memaccess -Wno-deprecated-copy -Wno-ignored-qualifiers -Wno-aligned-new -Wno-format-truncation -Wno-literal-suffix -Wno-format-overflow -Wno-stringop-truncation -Wno-memset-elt-size -Wno-cast-function-type -Wno-address-of-packed-member -DSUPPORT_SSE4_2 -fsanitize=address -fstack-protector-strong -fno-optimize-sibling-calls -fno-omit-frame-pointer -static-libasan -fno-var-tracking-assignments -fno-optimize-sibling-calls -fno-inline -DUSING_ASAN -DHAVE_SCHED_GETCPU -DHAVE_REALTIME_COARSE -DOB_HAVE_EVENTFD -DHAVE_FALLOCATE -DHAVA_BEYONDTRUST -DHAVE_MINIDUMP -Werror

    can help me or some suggestions

    opened by lemon0910 0
  • LeakSanitizer crash on 32 bit

    LeakSanitizer crash on 32 bit

    ==4414==Processing thread 4360. ==4414==Stack at 0xff5a1000-0xffda1000 (SP = 0xffd9cce0). ==4414==TLS at 0xf1b5c000-0xf1b63820. Tracer caught signal 11: addr=0xe9d00000 pc=0x80c1dd0 sp=0xeb4ffd60 ==4360==LeakSanitizer has encountered a fatal error. ==4360==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1 ==4360==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)

    i have tried to close tls with this but result is same.

    export LSAN_OPTIONS=verbosity=1:log_threads=1:intercept_tls_get_addr=0:fast_unwind_on_malloc=1:use_tls=0:abort_on_error=1 UBSAN_OPTIONS=print_stacktrace=1

    after I enable log_pointers I get following output: ==4043==Ignored: chunk 0xee001a20-0xee001ad0 of size 176. ==4043==Ignored: chunk 0xee001d90-0xee001e40 of size 176. ==4043==Scanning GLOBAL range 0x081d99e0-0x081e1240. ==4043==0x081ddc70: found 0xf060cb60 pointing into chunk 0xf060cb60-0xf060cb74 of size 20. ==4043==0x081de3f0: found 0xf0600480 pointing into chunk 0xf0600480-0xf0600494 of size 20. ==4043==Scanning GLOBAL range 0x08203100-0x0862fc60. ==4043==Scanning GLOBAL range 0xf7713000-0xf7717874. ==4043==Scanning GLOBAL range 0xf76420e4-0xf7643f38. ==4043==Scanning GLOBAL range 0xf75cc000-0xf7610c60. ==4043==0xf760ce48: found 0xe9a96929 pointing into chunk 0xe9a96920-0xe9ee6965 of size 4522053. ==4043==0xf760d320: found 0xeea5b500 pointing into chunk 0xeea5b500-0xeea5b508 of size 8. ==4043==0xf760ddb0: found 0xeea5bc90 pointing into chunk 0xeea5bc90-0xeea5bc94 of size 4. ==4043==0xf760dde0: found 0xeea5c620 pointing into chunk 0xeea5c620-0xeea5c624 of size 4. ==4043==0xf760dde4: found 0xeea5c410 pointing into chunk 0xeea5c410-0xeea5c414 of size 4. ==4043==0xf760ec1c: found 0xe6201a60 pointing into chunk 0xe6201a60-0xe6201a67 of size 7. ==4043==0xf760f7c4: found 0xefe00f40 pointing into chunk 0xefe00f40-0xefe00f74 of size 52. ==4043==0xf760fc14: found 0xf001b4e0 pointing into chunk 0xf001b4e0-0xf001b504 of size 36. ==4043==0xf760fc18: found 0xee86aa40 pointing into chunk 0xee86aa40-0xee86aa60 of size 32. ==4043==0xf7610880: found 0xefe00f00 pointing into chunk 0xefe00f00-0xefe00f34 of size 52. ==4043==Scanning GLOBAL range 0xf6e30a54-0xf6e30c38. ==4043==Scanning GLOBAL range 0xf6e269f8-0xf6e28d30. ==4043==Scanning GLOBAL range 0xf6e0bc38-0xf6e0efb0. ==4043==0xf6e0ced8: found 0xed203000 pointing into chunk 0xed203000-0xed203800 of size 2048. ==4043==0xf6e0eb08: found 0xee8579e0 pointing into chunk 0xee8579e0-0xee857a00 of size 32. ==4043==0xf6e0eb14: found 0xece00ff5 pointing into chunk 0xece00000-0xece01ff0 of size 8176. ==4043==0xf6e0eb60: found 0xee867640 pointing into chunk 0xee867640-0xee867660 of size 32. ==4043==0xf6e0eb70: found 0xee8652a0 pointing into chunk 0xee8652a0-0xee8652c0 of size 32. ==4043==0xf6e0eb74: found 0xf0018c60 pointing into chunk 0xf0018c60-0xf0018c90 of size 48. ==4043==0xf6e0eb78: found 0xf0018d20 pointing into chunk 0xf0018d20-0xf0018d50 of size 48. ==4043==0xf6e0eb7c: found 0xf001a820 pointing into chunk 0xf001a820-0xf001a841 of size 33. ==4043==0xf6e0eb80: found 0xeea5ca40 pointing into chunk 0xeea5ca40-0xeea5ca48 of size 8. ==4043==0xf6e0eb84: found 0xee867860 pointing into chunk 0xee867860-0xee867880 of size 32. ==4043==0xf6e0eba0: found 0xee8678c0 pointing into chunk 0xee8678c0-0xee8678d4 of size 20. ==4043==0xf6e0ece0: found 0xed203800 pointing into chunk 0xed203800-0xed204000 of size 2048. ==4043==0xf6e0ed0c: found 0xeea5be70 pointing into chunk 0xeea5be70-0xeea5be7c of size 12. ==4043==0xf6e0ed10: found 0xeea5c3d0 pointing into chunk 0xeea5c3d0-0xeea5c3dc of size 12. ==4043==0xf6e0ef60: found 0xeea5d1b0 pointing into chunk 0xeea5d1b0-0xeea5d1b4 of size 4. ==4043==Scanning GLOBAL range 0xf6cf1000-0xf6cf17e0. ==4043==0xf6cf17d8: found 0xeea5bfb0 pointing into chunk 0xeea5bfb0-0xeea5bfbc of size 12. ==4043==Scanning GLOBAL range 0xf6cdeeb0-0xf6cdf074. ==4043==Scanning GLOBAL range 0xf6cd9000-0xf6cda8d4. ==4043==Scanning GLOBAL range 0xf6c5a000-0xf6c619c0. ==4043==Scanning GLOBAL range 0xf6887a30-0xf68d8c40. ==4043==0xf68ccc00: found 0xe8284d20 pointing into chunk 0xe8284d20-0xe8284d50 of size 48. ==4043==0xf68ccc10: found 0xe7676800 pointing into chunk 0xe7676800-0xe7676810 of size 16. ==4043==Scanning GLOBAL range 0xf552575c-0xf5538de4. ==4043==0xf553656c: found 0xf0696a40 pointing into chunk 0xf0696a40-0xf0696a54 of size 20. ==4043==0xf5536570: found 0xf0697980 pointing into chunk 0xf0697980-0xf0697994 of size 20. ==4043==Scanning GLOBAL range 0xf4d2634c-0xf4d29c34. ==4043==Scanning GLOBAL range 0xf4c815e8-0xf4c81cb8. ==4043==Scanning GLOBAL range 0xf4c6dd7c-0xf4c70d94. ==4043==Scanning GLOBAL range 0xf4ba449c-0xf4ba66e0. ==4043==Scanning GLOBAL range 0xf4b1d628-0xf4b3fb38. ==4043==Scanning GLOBAL range 0xf42627ec-0xf4264ac4. ==4043==Scanning GLOBAL range 0xf41ee000-0xf41eed7c. ==4043==Scanning GLOBAL range 0xf41cd434-0xf41d28dc. ==4043==Scanning GLOBAL range 0xf4056000-0xf4059da0. ==4043==Scanning GLOBAL range 0xf3f6e620-0xf3f73960. ==4043==Scanning GLOBAL range 0xf3e34000-0xf3e38f78. ==4043==Scanning GLOBAL range 0xf3cd36cc-0xf3cd7b7c. ==4043==Scanning GLOBAL range 0xf3bcf070-0xf3bdee2c. ==4043==Scanning GLOBAL range 0xf3a21000-0xf3a275e0. ==4043==Scanning GLOBAL range 0xf3958000-0xf395ae24. ==4043==Scanning GLOBAL range 0xf3893064-0xf3897fc4. ==4043==Scanning GLOBAL range 0xf374d878-0xf374dc60. ==4043==Scanning GLOBAL range 0xf3731628-0xf3732d7c. ==4043==Scanning GLOBAL range 0xf36da118-0xf36dce54. ==4043==Scanning GLOBAL range 0xf3637ed8-0xf363bfe8. ==4043==Scanning GLOBAL range 0xf3529644-0xf3537df4. ==4043==Scanning GLOBAL range 0xf3205000-0xf32056f0. ==4043==Scanning GLOBAL range 0xf31f37dc-0xf31f5c7c. ==4043==Scanning GLOBAL range 0xf314f000-0xf318791c. ==4043==Scanning GLOBAL range 0xf24d79f8-0xf255db08. ==4043==Scanning GLOBAL range 0xf20cfec8-0xf20d0234. ==4043==Scanning GLOBAL range 0xf20c6ed8-0xf20c7080. ==4043==Scanning GLOBAL range 0xf209ad90-0xf209d1e0. ==4043==Scanning GLOBAL range 0xf20827c8-0xf2082b08. ==4043==Scanning GLOBAL range 0xf20601cc-0xf2065988. ==4043==0xf206235c: found 0xeea51008 pointing into chunk 0xeea51000-0xeea5100c of size 12. ==4043==0xf20629b4: found 0xeea51010 pointing into chunk 0xeea51010-0xeea5101c of size 12. ==4043==0xf2062ca4: found 0xeea50fc0 pointing into chunk 0xeea50fc0-0xeea50fd0 of size 16. ==4043==0xf2062ca8: found 0xef403480 pointing into chunk 0xef403480-0xef4035b8 of size 312. ==4043==0xf2063ae0: found 0xeea50fe0 pointing into chunk 0xeea50fe0-0xeea50fed of size 13. ==4043==0xf2063ae4: found 0xeea50ff0 pointing into chunk 0xeea50ff0-0xeea50ff4 of size 4. ==4043==Scanning GLOBAL range 0xf7738c60-0xf77398f8. ==4043==Scanning GLOBAL range 0xf1ecc000-0xf1ecdde8. ==4043==Scanning GLOBAL range 0xf1e4a000-0xf1e4acf0. ==4043==Scanning GLOBAL range 0xf1e32518-0xf1e327a0. ==4043==Scanning GLOBAL range 0xf1e23000-0xf1e2328c. ==4043==Scanning GLOBAL range 0xf1e1a1a8-0xf1e1a3a0. ==4043==Scanning GLOBAL range 0xf1e0f000-0xf1e0f2a8. ==4043==Scanning GLOBAL range 0xf1e05588-0xf1e05740. ==4043==Scanning GLOBAL range 0xf1e02398-0xf1e02824. ==4043==0xf1e02820: found 0xeee02f20 pointing into chunk 0xeee02f20-0xeee02fe4 of size 196. ==4043==Scanning GLOBAL range 0xf1dea000-0xf1ded620. ==4043==Scanning GLOBAL range 0xf1d54940-0xf1d55964. ==4043==0xf1d556a8: found 0xed603c00 pointing into chunk 0xed603c00-0xed603e90 of size 656. ==4043==0xf1d556e0: found 0xee855fe0 pointing into chunk 0xee855fe0-0xee856000 of size 32. ==4043==0xf1d55860: found 0xeea5bac0 pointing into chunk 0xeea5bac0-0xeea5bacc of size 12. ==4043==0xf1d55868: found 0xeea5c710 pointing into chunk 0xeea5c710-0xeea5c71c of size 12. ==4043==0xf1d5586c: found 0xeea5bfd0 pointing into chunk 0xeea5bfd0-0xeea5bfdc of size 12. ==4043==0xf1d55870: found 0xeea5c6f0 pointing into chunk 0xeea5c6f0-0xeea5c6fc of size 12. ==4043==0xf1d55874: found 0xeea5b9e0 pointing into chunk 0xeea5b9e0-0xeea5b9ec of size 12. ==4043==0xf1d55878: found 0xeea539a0 pointing into chunk 0xeea539a0-0xeea539ac of size 12. ==4043==0xf1d55880: found 0xeea547d0 pointing into chunk 0xeea547d0-0xeea547dc of size 12. ==4043==0xf1d55884: found 0xeea5b540 pointing into chunk 0xeea5b540-0xeea5b54c of size 12. ==4043==0xf1d55898: found 0xeea5c7c0 pointing into chunk 0xeea5c7c0-0xeea5c7cc of size 12. ==4043==0xf1d5589c: found 0xeea55250 pointing into chunk 0xeea55250-0xeea5525c of size 12. ==4043==0xf1d558a0: found 0xeea5c7a0 pointing into chunk 0xeea5c7a0-0xeea5c7ac of size 12. ==4043==0xf1d558a8: found 0xeea5bae0 pointing into chunk 0xeea5bae0-0xeea5baec of size 12. ==4043==0xf1d558ac: found 0xeea5bfc0 pointing into chunk 0xeea5bfc0-0xeea5bfcc of size 12. ==4043==0xf1d558b0: found 0xeea5c000 pointing into chunk 0xeea5c000-0xeea5c00c of size 12. ==4043==0xf1d558b4: found 0xeea5c790 pointing into chunk 0xeea5c790-0xeea5c79c of size 12. ==4043==0xf1d558b8: found 0xeea5c800 pointing into chunk 0xeea5c800-0xeea5c80c of size 12. ==4043==0xf1d558c0: found 0xeea5b920 pointing into chunk 0xeea5b920-0xeea5b92c of size 12. ==4043==0xf1d558c8: found 0xeea5bcc0 pointing into chunk 0xeea5bcc0-0xeea5bccc of size 12. ==4043==0xf1d558cc: found 0xeea54180 pointing into chunk 0xeea54180-0xeea5418c of size 12. ==4043==0xf1d558d0: found 0xeea5c6d0 pointing into chunk 0xeea5c6d0-0xeea5c6dc of size 12. ==4043==0xf1d558d4: found 0xeea5b930 pointing into chunk 0xeea5b930-0xeea5b93c of size 12. ==4043==0xf1d558d8: found 0xeea5b9f0 pointing into chunk 0xeea5b9f0-0xeea5b9fc of size 12. ==4043==0xf1d558e0: found 0xee862860 pointing into chunk 0xee862860-0xee862880 of size 32. ==4043==0xf1d558e4: found 0xee864400 pointing into chunk 0xee864400-0xee86441b of size 27. ==4043==0xf1d558e8: found 0xee863c20 pointing into chunk 0xee863c20-0xee863c36 of size 22. ==4043==0xf1d558ec: found 0xee8635c0 pointing into chunk 0xee8635c0-0xee8635dc of size 28. ==4043==0xf1d558f0: found 0xee863900 pointing into chunk 0xee863900-0xee863915 of size 21. ==4043==0xf1d558f4: found 0xee864020 pointing into chunk 0xee864020-0xee864034 of size 20. ==4043==0xf1d558f8: found 0xee8643e0 pointing into chunk 0xee8643e0-0xee8643f8 of size 24. ==4043==0xf1d558fc: found 0xee8639a0 pointing into chunk 0xee8639a0-0xee8639b5 of size 21. ==4043==0xf1d55900: found 0xee863a40 pointing into chunk 0xee863a40-0xee863a52 of size 18. ==4043==0xf1d55904: found 0xee863120 pointing into chunk 0xee863120-0xee863131 of size 17. ==4043==0xf1d55908: found 0xee8625a0 pointing into chunk 0xee8625a0-0xee8625ba of size 26. ==4043==0xf1d5590c: found 0xf001a160 pointing into chunk 0xf001a160-0xf001a185 of size 37. ==4043==0xf1d55910: found 0xee862820 pointing into chunk 0xee862820-0xee86283e of size 30. ==4043==0xf1d55914: found 0xf001a100 pointing into chunk 0xf001a100-0xf001a121 of size 33. ==4043==0xf1d55918: found 0xee854e60 pointing into chunk 0xee854e60-0xee854e7a of size 26. ==4043==0xf1d5591c: found 0xee863f40 pointing into chunk 0xee863f40-0xee863f5b of size 27. ==4043==0xf1d55920: found 0xee8630c0 pointing into chunk 0xee8630c0-0xee8630d7 of size 23. ==4043==0xf1d55924: found 0xee8626c0 pointing into chunk 0xee8626c0-0xee8626d8 of size 24. ==4043==0xf1d55928: found 0xee863840 pointing into chunk 0xee863840-0xee863857 of size 23. ==4043==0xf1d5592c: found 0xee8629e0 pointing into chunk 0xee8629e0-0xee8629fd of size 29. ==4043==0xf1d55930: found 0xee863ca0 pointing into chunk 0xee863ca0-0xee863cbf of size 31. ==4043==0xf1d55934: found 0xee856e60 pointing into chunk 0xee856e60-0xee856e76 of size 22. ==4043==0xf1d55938: found 0xee864cc0 pointing into chunk 0xee864cc0-0xee864cdc of size 28. ==4043==0xf1d5593c: found 0xee863620 pointing into chunk 0xee863620-0xee863639 of size 25. ==4043==0xf1d55940: found 0xee863960 pointing into chunk 0xee863960-0xee863979 of size 25. ==4043==0xf1d55944: found 0xee8638a0 pointing into chunk 0xee8638a0-0xee8638b6 of size 22. ==4043==0xf1d55948: found 0xee856e80 pointing into chunk 0xee856e80-0xee856e91 of size 17. ==4043==0xf1d5594c: found 0xf001a190 pointing into chunk 0xf001a190-0xf001a1b1 of size 33. ==4043==0xf1d55950: found 0xee864760 pointing into chunk 0xee864760-0xee86477d of size 29. ==4043==0xf1d55954: found 0xee862fa0 pointing into chunk 0xee862fa0-0xee862fb7 of size 23. ==4043==0xf1d55958: found 0xee8637e0 pointing into chunk 0xee8637e0-0xee863800 of size 32. ==4043==0xf1d5595c: found 0xef601c20 pointing into chunk 0xef601c20-0xef601c6c of size 76. ==4043==Scanning GLOBAL range 0xf1d16888-0xf1d1f6b8. ==4043==0xf1d1d1f8: found 0xf0800000 pointing into chunk 0xf0800000-0xf0804a00 of size 18944. ==4043==Scanning GLOBAL range 0xf1b3d37c-0xf1b3d5a4. ==4043==Scanning GLOBAL range 0xf1b38000-0xf1b38308. ==4043==Scanning GLOBAL range 0xf1b14000-0xf1b17298. ==4043==Scanning GLOBAL range 0xf1ad3518-0xf1ad3680. ==4043==Scanning GLOBAL range 0xf1ad0000-0xf1ad0188. ==4043==Scanning GLOBAL range 0xf1acb4d8-0xf1acb5f8. ==4043==Scanning GLOBAL range 0xf1ac9000-0xf1ac9a88. ==4043==Scanning GLOBAL range 0xf1ab1000-0xf1ab11c0. ==4043==Scanning GLOBAL range 0xf1aab61c-0xf1aabd28. ==4043==Scanning GLOBAL range 0xf1a9ee78-0xf1a9fc04. ==4043==Scanning GLOBAL range 0xf1a7d398-0xf1a80914. ==4043==Scanning GLOBAL range 0xf1a237c4-0xf1a24ffc. ==4043==Scanning GLOBAL range 0xf19fcac0-0xf19fcc44. ==4043==0xf19fcc40: found 0xee855c80 pointing into chunk 0xee855c80-0xee855c97 of size 23. ==4043==Processing thread 3979. ==4043==Scanning REGISTERS range 0xf0dcc000-0xf0dcc044. ==4043==Stack at 0xff03f000-0xff83f000 (SP = 0xff83aed0). ==4043==Scanning STACK range 0xff83aed0-0xff83f000. ==4043==Scanning HEAP range 0xee855c80-0xee855c97. ==4043==Scanning HEAP range 0xf0800000-0xf0804a00. ==4043==Scanning HEAP range 0xef601c20-0xef601c6c. ==4043==0xef601c20: found 0xeea5bb50 pointing into chunk 0xeea5bb50-0xeea5bb60 of size 16. ==4043==0xef601c24: found 0xeea5bf10 pointing into chunk 0xeea5bf10-0xeea5bf1c of size 12. ==4043==0xef601c28: found 0xeea5ba80 pointing into chunk 0xeea5ba80-0xeea5ba90 of size 16. ==4043==0xef601c2c: found 0xeea5bbf0 pointing into chunk 0xeea5bbf0-0xeea5bc00 of size 16. ==4043==0xef601c30: found 0xeea5ba70 pointing into chunk 0xeea5ba70-0xeea5ba80 of size 16. ==4043==0xef601c34: found 0xeea5c7e0 pointing into chunk 0xeea5c7e0-0xeea5c7ec of size 12. ==4043==0xef601c38: found 0xeea5ce00 pointing into chunk 0xeea5ce00-0xeea5ce0c of size 12. ==4043==0xef601c3c: found 0xeea545a0 pointing into chunk 0xeea545a0-0xeea545ac of size 12. ==4043==0xef601c44: found 0xeea5b990 pointing into chunk 0xeea5b990-0xeea5b9a0 of size 16. ==4043==0xef601c48: found 0xeea5b4a0 pointing into chunk 0xeea5b4a0-0xeea5b4b0 of size 16. ==4043==0xef601c4c: found 0xeea53d30 pointing into chunk 0xeea53d30-0xeea53d3c of size 12. ==4043==0xef601c50: found 0xeea5c020 pointing into chunk 0xeea5c020-0xeea5c02c of size 12. ==4043==0xef601c54: found 0xeea5ba10 pointing into chunk 0xeea5ba10-0xeea5ba1c of size 12. ==4043==0xef601c68: found 0xed001000 pointing into chunk 0xed001000-0xed001ff8 of size 4088. ==4043==Scanning HEAP range 0xed001000-0xed001ff8. ==4043==0xed001000: found 0xed003000 pointing into chunk 0xed003000-0xed003ff8 of size 4088. ==4043==0xed00100c: found 0xf0019e38 pointing into chunk 0xf0019e30-0xf0019e52 of size 34. ==4043==0xed001024: found 0xee865f08 pointing into chunk 0xee865f00-0xee865f1b of size 27. ==4043==0xed001030: found 0xee864968 pointing into chunk 0xee864960-0xee86497a of size 26. ==4043==0xed00103c: found 0xee866a08 pointing into chunk 0xee866a00-0xee866a16 of size 22. ==4043==0xed001048: found 0xee8669e8 pointing into chunk 0xee8669e0-0xee8669fa of size 26. ==4043==0xed001054: found 0xee8669c8 pointing into chunk 0xee8669c0-0xee8669d6 of size 22. ==4043==0xed001060: found 0xee863568 pointing into chunk 0xee863560-0xee86357c of size 28. ==4043==0xed001078: found 0xee862be8 pointing into chunk 0xee862be0-0xee862bfc of size 28. ==4043==0xed0010b4: found 0xee8649c8 pointing into chunk 0xee8649c0-0xee8649e0 of size 32. ==4043==0xed0010cc: found 0xee8669a8 pointing into chunk 0xee8669a0-0xee8669b9 of size 25. ==4043==0xed0010d8: found 0xee8649a8 pointing into chunk 0xee8649a0-0xee8649b4 of size 20. ==4043==0xed0010f0: found 0xee8609a8 pointing into chunk 0xee8609a0-0xee8609ba of size 26. ==4043==0xed0010fc: found 0xee865e68 pointing into chunk 0xee865e60-0xee865e76 of size 22. ==4043==0xed001108: found 0xee865e28 pointing into chunk 0xee865e20-0xee865e3a of size 26. ==4043==0xed001114: found 0xee865e08 pointing into chunk 0xee865e00-0xee865e1b of size 27. ==4043==0xed001120: found 0xee865de8 pointing into chunk 0xee865de0-0xee865df8 of size 24. ==4043==0xed00112c: found 0xee865dc8 pointing into chunk 0xee865dc0-0xee865dda of size 26. ==4043==0xed001138: found 0xee865da8 pointing into chunk 0xee865da0-0xee865dbb of size 27. ==4043==0xed001144: found 0xee865d88 pointing into chunk 0xee865d80-0xee865d9b of size 27. ==4043==0xed001150: found 0xee865d68 pointing into chunk 0xee865d60-0xee865d7a of size 26. ==4043==0xed00115c: found 0xee865d48 pointing into chunk 0xee865d40-0xee865d59 of size 25. ==4043==0xed001168: found 0xee865d28 pointing into chunk 0xee865d20-0xee865d39 of size 25. ==4043==0xed001174: found 0xee865d08 pointing into chunk 0xee865d00-0xee865d1a of size 26. ==4043==0xed001180: found 0xee865ce8 pointing into chunk 0xee865ce0-0xee865cf8 of size 24. ==4043==0xed00118c: found 0xee865cc8 pointing into chunk 0xee865cc0-0xee865cd2 of size 18. ==4043==0xed001198: found 0xee865ca8 pointing into chunk 0xee865ca0-0xee865cbc of size 28. ==4043==0xed0011a4: found 0xee865c88 pointing into chunk 0xee865c80-0xee865c9a of size 26. ==4043==0xed0011b0: found 0xee865c68 pointing into chunk 0xee865c60-0xee865c79 of size 25. ==4043==0xed0011bc: found 0xee865c48 pointing into chunk 0xee865c40-0xee865c58 of size 24. ==4043==0xed0011c8: found 0xee865c28 pointing into chunk 0xee865c20-0xee865c32 of size 18. ==4043==0xed001504: found 0xee866948 pointing into chunk 0xee866940-0xee866958 of size 24. ==4043==0xed001558: found 0xee865f88 pointing into chunk 0xee865f80-0xee865f96 of size 22. ==4043==0xed001564: found 0xee866928 pointing into chunk 0xee866920-0xee86693b of size 27. ==4043==0xed001570: found 0xee8648e8 pointing into chunk 0xee8648e0-0xee8648f4 of size 20. ==4043==0xed00157c: found 0xee866908 pointing into chunk 0xee866900-0xee866914 of size 20. ==4043==0xed001594: found 0xee8668e8 pointing into chunk 0xee8668e0-0xee866900 of size 32. ==4043==0xed0015a0: found 0xee865ee8 pointing into chunk 0xee865ee0-0xee865ef6 of size 22. ==4043==0xed0015d0: found 0xee864bc8 pointing into chunk 0xee864bc0-0xee864bd5 of size 21. ==4043==0xed0015e8: found 0xee856668 pointing into chunk 0xee856660-0xee85667b of size 27. ==4043==0xed00160c: found 0xee8668c8 pointing into chunk 0xee8668c0-0xee8668d5 of size 21. ==4043==0xed001618: found 0xee8668a8 pointing into chunk 0xee8668a0-0xee8668b7 of size 23. ==4043==0xed001624: found 0xee866888 pointing into chunk 0xee866880-0xee86689b of size 27. ==4043==0xed001630: found 0xee866868 pointing into chunk 0xee866860-0xee866875 of size 21. ==4043==0xed00163c: found 0xee866848 pointing into chunk 0xee866840-0xee866853 of size 19. ==4043==0xed001648: found 0xee866828 pointing into chunk 0xee866820-0xee866837 of size 23. ==4043==0xed001654: found 0xee866a28 pointing into chunk 0xee866a20-0xee866a3d of size 29. ==4043==0xed001660: found 0xee865fa8 pointing into chunk 0xee865fa0-0xee865fbb of size 27. ==4043==0xed001960: found 0xee864b28 pointing into chunk 0xee864b20-0xee864b32 of size 18. ==4043==0xed00196c: found 0xee864b88 pointing into chunk 0xee864b80-0xee864b96 of size 22. ==4043==0xed001978: found 0xee8667c8 pointing into chunk 0xee8667c0-0xee8667d5 of size 21. ==4043==0xed001984: found 0xee8667a8 pointing into chunk 0xee8667a0-0xee8667b5 of size 21. ==4043==0xed0019b4: found 0xee864948 pointing into chunk 0xee864940-0xee864955 of size 21. ==4043==0xed0019c0: found 0xee866748 pointing into chunk 0xee866740-0xee86675d of size 29. ==4043==0xed0019cc: found 0xee866728 pointing into chunk 0xee866720-0xee86673a of size 26. ==4043==0xed001a2c: found 0xee8648c8 pointing into chunk 0xee8648c0-0xee8648d5 of size 21. ==4043==0xed001a38: found 0xee866688 pointing into chunk 0xee866680-0xee866696 of size 22. ==4043==0xed001a44: found 0xee866648 pointing into chunk 0xee866640-0xee866652 of size 18. ==4043==0xed001a50: found 0xee8665c8 pointing into chunk 0xee8665c0-0xee8665d2 of size 18. ==4043==0xed001a5c: found 0xee865608 pointing into chunk 0xee865600-0xee865612 of size 18. ==4043==0xed001a74: found 0xee866480 pointing into chunk 0xee866480-0xee8664a0 of size 32. ==4043==0xed001a98: found 0xee8654a8 pointing into chunk 0xee8654a0-0xee8654b4 of size 20. ==4043==0xed001ab0: found 0xee866408 pointing into chunk 0xee866400-0xee866413 of size 19. ==4043==0xed001ad4: found 0xee866388 pointing into chunk 0xee866380-0xee866391 of size 17. ==4043==Scanning HEAP range 0xee866380-0xee866391. ==4043==0xee866380: found 0xefe05440 pointing into chunk 0xefe05440-0xefe05474 of size 52. ==4043==Scanning HEAP range 0xefe05440-0xefe05474. ==4043==0xefe05440: found 0xee86ea00 pointing into chunk 0xee86ea00-0xee86ea18 of size 24. ==4043==Scanning HEAP range 0xee86ea00-0xee86ea18. ==4043==0xee86ea00: found 0xefe06bc0 pointing into chunk 0xefe06bc0-0xefe06bf8 of size 56. ==4043==Scanning HEAP range 0xefe06bc0-0xefe06bf8. ==4043==0xefe06bc0: found 0xefe06a40 pointing into chunk 0xefe06a40-0xefe06a78 of size 56. ==4043==Scanning HEAP range 0xefe06a40-0xefe06a78. ==4043==0xefe06a40: found 0xf001c0b0 pointing into chunk 0xf001c0b0-0xf001c0d1 of size 33. ==4043==Scanning HEAP range 0xf001c0b0-0xf001c0d1. ==4043==0xf001c0b0: found 0xf001bff0 pointing into chunk 0xf001bff0-0xf001c013 of size 35. ==4043==Scanning HEAP range 0xf001bff0-0xf001c013. ==4043==0xf001bff0: found 0xefe06040 pointing into chunk 0xefe06040-0xefe0607a of size 58. ==4043==Scanning HEAP range 0xefe06040-0xefe0607a. ==4043==Scanning HEAP range 0xee866400-0xee866413. ==4043==0xee866400: found 0xee86d020 pointing into chunk 0xee86d020-0xee86d033 of size 19. ==4043==Scanning HEAP range 0xee86d020-0xee86d033. ==4043==0xee86d020: found 0xee86ec60 pointing into chunk 0xee86ec60-0xee86ec74 of size 20. ==4043==Scanning HEAP range 0xee86ec60-0xee86ec74. ==4043==0xee86ec60: found 0xefe05200 pointing into chunk 0xefe05200-0xefe05234 of size 52. ==4043==Scanning HEAP range 0xefe05200-0xefe05234. ==4043==0xefe05200: found 0xefe04fc0 pointing into chunk 0xefe04fc0-0xefe04ffa of size 58. ==4043==Scanning HEAP range 0xefe04fc0-0xefe04ffa. ==4043==0xefe04fc0: found 0xef6039d0 pointing into chunk 0xef6039d0-0xef603a12 of size 66. ==4043==Scanning HEAP range 0xef6039d0-0xef603a12. ==4043==0xef6039d0: found 0xefe06c40 pointing into chunk 0xefe06c40-0xefe06c78 of size 56. ==4043==Scanning HEAP range 0xefe06c40-0xefe06c78. ==4043==0xefe06c44: found 0xe9cb03da pointing into chunk 0xe9cb03c0-0xe9cb0421 of size 97. ==4043==Scanning HEAP range 0xe9cb03c0-0xe9cb0421. ==4043==Scanning HEAP range 0xee8654a0-0xee8654b4. ==4043==Scanning HEAP range 0xee866480-0xee8664a0. ==4043==Scanning HEAP range 0xee865600-0xee865612. ==4043==0xee865600: found 0xee863d40 pointing into chunk 0xee863d40-0xee863d58 of size 24. ==4043==Scanning HEAP range 0xee863d40-0xee863d58. ==4043==0xee863d40: found 0xf001a070 pointing into chunk 0xf001a070-0xf001a092 of size 34. ==4043==Scanning HEAP range 0xf001a070-0xf001a092. ==4043==0xf001a070: found 0xee863a60 pointing into chunk 0xee863a60-0xee863a75 of size 21. ==4043==Scanning HEAP range 0xee863a60-0xee863a75. ==4043==Scanning HEAP range 0xee8665c0-0xee8665d2. ==4043==0xee8665c0: found 0xee86dec0 pointing into chunk 0xee86dec0-0xee86ded4 of size 20. ==4043==Scanning HEAP range 0xee86dec0-0xee86ded4. ==4043==0xee86dec0: found 0xee86e360 pointing into chunk 0xee86e360-0xee86e37e of size 30. ==4043==Scanning HEAP range 0xee86e360-0xee86e37e. ==4043==0xee86e360: found 0xefe06800 pointing into chunk 0xefe06800-0xefe06838 of size 56. ==4043==Scanning HEAP range 0xefe06800-0xefe06838. ==4043==0xefe06804: found 0xe9cb739a pointing into chunk 0xe9cb7380-0xea3773f3 of size 7078003. ==4043==Scanning HEAP range 0xe9cb7380-0xea3773f3. Tracer caught signal 11: addr=0xe9d00000 pc=0x80c1eb0 sp=0xeb2ffd60 ==3979==LeakSanitizer has encountered a fatal error. ==3979==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1 ==3979==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)

    opened by memfissoftware 2
  • ASAN not reporting out of bounds access in a global array

    ASAN not reporting out of bounds access in a global array

    ASAN is not reporting the following test case:

    $ cat test.cpp
    int A[10];
    
    int main()
    {
            A[10] = 10;
            A[11] = 11;
    //      A[12] = 12;
    
            return 0;
    }
    

    Here are the commands for reproducing the issue:

    $ clang++ -fsanitize=address test.cpp
    test.cpp:5:2: warning: array index 10 is past the end of the array (which contains 10 elements) [-Warray-bounds]
            A[10] = 10;
            ^ ~~
    test.cpp:1:1: note: array 'A' declared here
    int A[10];
    ^
    test.cpp:6:2: warning: array index 11 is past the end of the array (which contains 10 elements) [-Warray-bounds]
            A[11] = 11;
            ^ ~~
    test.cpp:1:1: note: array 'A' declared here
    int A[10];
    ^
    2 warnings generated.
    $ ./a.out
    $
    

    I have gone through the LLVM IR and found out that these two accesses are not even instrumented. As I have a debug build, I found out that the above accesses A[10], A[11] were deemed as safe accesses by AddressSanitizer::isSafeAccess() in llvm-project/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp, and hence they are never instrumented.

    Is this expected from ASAN or is the judgement of safety of an access wrong or am I missing something ?

    opened by sandeepkosuri 1
Owner
Google
Google ❤️ Open Source
Google