Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ASAN: AddressSanitizer CHECK failed: ((m)) != (0)" (0x0, 0x0) #1193

Closed
vitalybuka opened this issue Feb 10, 2020 · 4 comments
Closed

ASAN: AddressSanitizer CHECK failed: ((m)) != (0)" (0x0, 0x0) #1193

vitalybuka opened this issue Feb 10, 2020 · 4 comments

Comments

@vitalybuka
Copy link
Contributor

vitalybuka commented Feb 10, 2020

Very rarely we've seen this CHECK failed in asan allocator
There is no known reproducer yet.

==4979==AddressSanitizer CHECK failed: llvm-project/compiler-rt/lib/asan/asan_allocator.cpp:1042 "((m)) != (0)" (0x0, 0x0)
Tracer caught signal 11: addr=0x8 pc=0x7f524740f420 sp=0x7f5235268160
==4971==LeakSanitizer has encountered a fatal error.
==4971==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==4971==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
E0206 05:42:07.026651 4971 allocator.cc:232] RAW:

Internal Google bug: http://b/149237057

kcc added a commit to llvm/llvm-project that referenced this issue Jun 2, 2020
…ers#1193

Summary: add debug code to chase down a rare crash in asan/lsan google/sanitizers#1193

Reviewers: vitalybuka

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D80967
arichardson pushed a commit to arichardson/llvm-project that referenced this issue Jul 6, 2020
…ers#1193

Summary: add debug code to chase down a rare crash in asan/lsan google/sanitizers#1193

Reviewers: vitalybuka

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D80967
kcc added a commit to llvm/llvm-project that referenced this issue Jul 29, 2020
…t being able to reproduce it for a few months, but the users are seeing it)

mode debug code

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D84819
hanswinderix pushed a commit to hanswinderix/llvm-project that referenced this issue Aug 5, 2020
…t being able to reproduce it for a few months, but the users are seeing it)

mode debug code

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D84819
@jzern
Copy link

jzern commented Aug 25, 2020

I just got this with a note to update this issue:
chunk: 0x7f8dc206a000 caller 0x56245194de32 __lsan_current_stage CollectIgnoredCb
==1566==AddressSanitizer CHECK failed: third_party/llvm/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp:1053 "((m)) != (0)" (0x0, 0x0)
Tracer caught signal 11: addr=0x0 pc=0x7f911d152e91 sp=0x7f8dc2024550

sponge2/c301a9e8-8839-4215-b0aa-b01c99883e93

@vitalybuka
Copy link
Contributor Author

Thanks, I'll take a look.

@vitalybuka
Copy link
Contributor Author

vitalybuka commented Sep 1, 2020

Reproducer

// RUN: %clangxx_asan -O2 %s -o %t && %run %t

#include <atomic>
#include <memory>
#include <thread>
#include <vector>
#include <sanitizer/lsan_interface.h>

std::atomic<bool> done;

void foo() {
  std::vector<std::unique_ptr<char[]>> mem(100);

  while (!done)
    mem[rand() % mem.size()].reset(new char[1000000]);
}

int main() {
  std::vector<std::thread> first;
  for (int i = 0; i < 100; ++i)
    first.emplace_back(foo);

  for (int i = 0; i < 1000; ++i)
    __lsan_do_recoverable_leak_check();

  done = true;
  for (auto &f : first)
    f.join();

  return 0;
}

@vitalybuka
Copy link
Contributor Author

Problem is here https://github.com/llvm/llvm-project/blob/63844c116a0acf8a75ebe4ed6f25fced3c655710/compiler-rt/lib/asan/asan_allocator.cpp#L465-L522

  1. allocator.Allocate allocate memblock under internal lock
  2. lsan waits for that lock, see LockAllocator
  3. allocator.Allocate release the lock and returns
  4. lsan "stops the word"
  5. allocator.Allocate is stopped somewhere before line 522 (meta[1] = chunk_beg)
  6. lsan calls GetUserBegin
  7. m is meta[1]
  8. So we fail CHECK(m)

vitalybuka added a commit to llvm/llvm-project that referenced this issue Sep 8, 2020
Used for google/sanitizers#1193

Reviewed By: morehouse

Differential Revision: https://reviews.llvm.org/D86933
arichardson pushed a commit to arichardson/llvm-project that referenced this issue Mar 21, 2021
…t being able to reproduce it for a few months, but the users are seeing it)

mode debug code

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D84819
arichardson pushed a commit to arichardson/llvm-project that referenced this issue Mar 23, 2021
Fixes google/sanitizers#1193.

AsanChunk can be uninitialized yet just after return from the secondary
allocator. If lsan starts scan just before metadata assignment it can
fail to find corresponding AsanChunk.

It should be safe to ignore this and let lsan to assume that
AsanChunk is in the beginning of the block. This block is from the
secondary allocator and created with mmap, so it should not contain
any pointers and will make lsan to miss some leaks.

Similar already happens for primary allocator. If it can't find real
AsanChunk it falls back and assume that block starts with AsanChunk.
Then if the block is already returned to allocator we have  garbage in
AsanChunk and may scan dead memory hiding some leaks.
I'll fix this in D87135.

Reviewed By: morehouse

Differential Revision: https://reviews.llvm.org/D86931
arichardson pushed a commit to arichardson/llvm-project that referenced this issue Mar 23, 2021
Used for google/sanitizers#1193

Reviewed By: morehouse

Differential Revision: https://reviews.llvm.org/D86933
jrtc27 pushed a commit to CTSRD-CHERI/compiler-rt that referenced this issue Jan 18, 2022
…t being able to reproduce it for a few months, but the users are seeing it)

mode debug code

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D84819
jrtc27 pushed a commit to CTSRD-CHERI/compiler-rt that referenced this issue Jan 18, 2022
Fixes google/sanitizers#1193.

AsanChunk can be uninitialized yet just after return from the secondary
allocator. If lsan starts scan just before metadata assignment it can
fail to find corresponding AsanChunk.

It should be safe to ignore this and let lsan to assume that
AsanChunk is in the beginning of the block. This block is from the
secondary allocator and created with mmap, so it should not contain
any pointers and will make lsan to miss some leaks.

Similar already happens for primary allocator. If it can't find real
AsanChunk it falls back and assume that block starts with AsanChunk.
Then if the block is already returned to allocator we have  garbage in
AsanChunk and may scan dead memory hiding some leaks.
I'll fix this in D87135.

Reviewed By: morehouse

Differential Revision: https://reviews.llvm.org/D86931
jrtc27 pushed a commit to CTSRD-CHERI/compiler-rt that referenced this issue Jan 18, 2022
Used for google/sanitizers#1193

Reviewed By: morehouse

Differential Revision: https://reviews.llvm.org/D86933
mem-frob pushed a commit to draperlaboratory/hope-llvm-project that referenced this issue Oct 7, 2022
…t being able to reproduce it for a few months, but the users are seeing it)

mode debug code

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D84819
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants