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:

Comments
  • 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 47
  • 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 31
  • 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
  • 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
  • ASAN SEGV's on mixed C++-C unit googletest

    ASAN SEGV's on mixed C++-C unit googletest

    The code at https://github.com/chaiken/util-scripts/commit/94cb15c4db31fdee5b7cf71938463e78c95d560a triggers a SEGV:

    ./cpumask_test Running main() from /home/alison/gitsrc/googletest/googletest/src/gtest_main.cc [==========] Running 3 tests from 1 test suite. [----------] Global test environment set-up. [----------] 3 tests from SimpleCpuMaskTest [ RUN ] SimpleCpuMaskTest.ParseSingleCore [ OK ] SimpleCpuMaskTest.ParseSingleCore (0 ms) [ RUN ] SimpleCpuMaskTest.BadCore [ OK ] SimpleCpuMaskTest.BadCore (27 ms) [ RUN ] SimpleCpuMaskTest.ParseRange AddressSanitizer:DEADLYSIGNAL

    ==775030==ERROR: AddressSanitizer: SEGV on unknown address 0x55b4116964f0 (pc 0x7f0ce722d357 bp 0x000000000002 sp 0x7ffd497047f0 T0) ==775030==The signal is caused by a WRITE memory access. #0 0x7f0ce722d357 in bool __sanitizer::atomic_compare_exchange_strong<__sanitizer::atomic_uint8_t>(__sanitizer::atomic_uint8_t volatile*, __sanitizer::atomic_uint8_t::Type*, __sanitizer::atomic_uint8_t::Type, __sanitizer::memory_order) ../../../../src/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h:80 #1 0x7f0ce722d357 in __asan::Allocator::AtomicallySetQuarantineFlagIfAllocated(__asan::AsanChunk*, void*, __sanitizer::BufferedStackTrace*) ../../../../src/libsanitizer/asan/asan_allocator.cpp:620 #2 0x7f0ce722d357 in __asan::Allocator::Deallocate(void*, unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType) ../../../../src/libsanitizer/asan/asan_allocator.cpp:696 #3 0x7f0ce72ba39d in operator delete(void*, unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:164 #4 0x55b411644db6 in std::_Sp_counted_ptr<char const*, (__gnu_cxx::_Lock_policy)2>::_M_dispose() /usr/include/c++/12/bits/shared_ptr_base.h:428 #5 0x55b41163539f in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() /usr/include/c++/12/bits/shared_ptr_base.h:346 #6 0x55b41163841b in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() /usr/include/c++/12/bits/shared_ptr_base.h:1071 #7 0x55b411637d35 in std::__shared_ptr<char const, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() /usr/include/c++/12/bits/shared_ptr_base.h:1524 #8 0x55b411637da3 in std::shared_ptr::~shared_ptr() /usr/include/c++/12/bits/shared_ptr.h:175 #9 0x55b411633e4b in SimpleCpuMaskTest_ParseRange_Test::TestBody() /home/alison/gitsrc/util-scripts/cpumask_testsuite.cc:50 #10 0x55b411680e24 in void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::)(), char const) (/home/alison/gitsrc/util-scripts/cpumask_test+0x83e24) #11 0x55b41167a0d6 in void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::)(), char const) (/home/alison/gitsrc/util-scripts/cpumask_test+0x7d0d6) #12 0x55b411657b5f in testing::Test::Run() (/home/alison/gitsrc/util-scripts/cpumask_test+0x5ab5f) #13 0x55b411658575 in testing::TestInfo::Run() (/home/alison/gitsrc/util-scripts/cpumask_test+0x5b575) #14 0x55b411658ddb in testing::TestSuite::Run() (/home/alison/gitsrc/util-scripts/cpumask_test+0x5bddb) #15 0x55b4116686c8 in testing::internal::UnitTestImpl::RunAllTests() (/home/alison/gitsrc/util-scripts/cpumask_test+0x6b6c8) #16 0x55b411681d5e in bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::)(), char const) (/home/alison/gitsrc/util-scripts/cpumask_test+0x84d5e) #17 0x55b41167b112 in bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::)(), char const) (/home/alison/gitsrc/util-scripts/cpumask_test+0x7e112) #18 0x55b411666f01 in testing::UnitTest::Run() (/home/alison/gitsrc/util-scripts/cpumask_test+0x69f01) #19 0x55b41169414a in RUN_ALL_TESTS() (/home/alison/gitsrc/util-scripts/cpumask_test+0x9714a) #20 0x55b4116940cf in main (/home/alison/gitsrc/util-scripts/cpumask_test+0x970cf) #21 0x7f0ce7046189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #22 0x7f0ce7046244 in __libc_start_main_impl ../csu/libc-start.c:381 #23 0x55b41162e090 in _start (/home/alison/gitsrc/util-scripts/cpumask_test+0x31090)

    AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV ../../../../src/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h:80 in bool __sanitizer::atomic_compare_exchange_strong<__sanitizer::atomic_uint8_t>(__sanitizer::atomic_uint8_t volatile*, __sanitizer::atomic_uint8_t::Type*, __sanitizer::atomic_uint8_t::Type, __sanitizer::memory_order) ==775030==ABORTING

    To reproduce:

    1. git clone [email protected]:chaiken/util-scripts.git
    2. git am 0001-reproduce-SEGV.patch
    3. make cpumask_test && ./cpumask_test

    The g++ version is 12.2.0.

    opened by chaiken 0
  • Thread limit (4194304 threads) exceeeded. Dying

    Thread limit (4194304 threads) exceeeded. Dying

    Dear exports,

    I have used AddressSanitizer for my code, and I got "AddressSanitizer: Thread limit (4194304 threads) exceeeded. Dying".

    My question is: is this my code's fault or a limitation in AddressSanitizer?

    How can I fix this?

    opened by cglwdm 0
  • Setting max_leaks results in contradictory output messages

    Setting max_leaks results in contradictory output messages

    I set max_leaks=100 and get the output below. The first line says that 5000 leaks will be reported. Then the second line says 100 leaks will be reported. The contradictory numbers are confusing.

    =================================================================
    ==18825==ERROR: LeakSanitizer: detected memory leaks
    
    Too many leaks! Only the first 5000 leaks encountered will be reported.
    The 100 top leak(s):
    ...
    
    opened by adayton1 0
  • Question on Clang's address sanitizer documentation

    Question on Clang's address sanitizer documentation

    In the Clang document on address sanitizer, under limitations (https://clang.llvm.org/docs/AddressSanitizer.html#limitations), the last bullet reads "Static linking of executables is not supported". That seems to contradict with my understanding that linking an executable with Clang using -fsanitize=address would make the executable statically links in the ASAN runtime library. What am I missing? Thanks.

    opened by kuanjen100 0
  • AddressSanitizer does not find out leak

    AddressSanitizer does not find out leak

    The source is :

    // address.c
    #include <stdlib.h>
    int main () {
        // unsigned char *buf[3];
        unsigned long buf[4];
    
        int stack_size = 10000;
        unsigned char *stack = (unsigned char *)calloc(10000, sizeof(int));
    
    
        // free(stack);
        return 0;
    }
    

    Compile with command: clang -g -O0 -fsanitize=address -fno-common -fno-omit-frame-pointer address.c -o exe (clang version is clang-10, Ubuntu 20) The result is: No leakage is found out. but when element number of buf is 3, the leakage is found out. Just like this:

    // address.c
    #include <stdlib.h>
    int main () {
        unsigned char *buf[3];
        // unsigned long buf[4];
    
        int stack_size = 10000;
        unsigned char *stack = (unsigned char *)calloc(10000, sizeof(int));
    
    
        // free(stack);
        return 0;
    }
    
    opened by curiousParrot 1
Owner
Google
Google ❤️ Open Source
Google