Currently we use very common names for macros like ACQUIRE/RELEASE,
which cause conflicts with system headers.
Prefix all macros with SANITIZER_ to avoid conflicts.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D116652
According comments on D44404, something like that was the goal.
Reviewed By: morehouse, kstoimenov
Differential Revision: https://reviews.llvm.org/D114991
Enable clang Thread Safety Analysis for sanitizers:
https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
Thread Safety Analysis can detect inconsistent locking,
deadlocks and data races. Without GUARDED_BY annotations
it has limited value. But this does all the heavy lifting
to enable analysis and allows to add GUARDED_BY incrementally.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D105716
Currently we have a bit of a mess related to tids:
- sanitizers re-declare kInvalidTid multiple times
- some call it kUnknownTid
- implicit assumptions that main tid is 0
- asan/memprof claim their tids need to fit into 24 bits,
but this does not seem to be true anymore
- inconsistent use of u32/int to store tids
Introduce kInvalidTid/kMainTid in sanitizer_common
and use them consistently.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D101428
Previously in ASan's `pthread_create` interceptor we would block in the
`pthread_create` interceptor waiting for the child thread to start.
Unfortunately this has bad performance characteristics because the OS
scheduler doesn't know the relationship between the parent and child
thread (i.e. the parent thread cannot make progress until the child
thread makes progress) and may make the wrong scheduling decision which
stalls progress.
It turns out that ASan didn't use to block in this interceptor but was
changed to do so to try to address
http://llvm.org/bugs/show_bug.cgi?id=21621/.
In that bug the problem being addressed was a LeakSanitizer false
positive. That bug concerns a heap object being passed
as `arg` to `pthread_create`. If:
* The calling thread loses a live reference to the object (e.g.
`pthread_create` finishes and the thread no longer has a live
reference to the object).
* Leak checking is triggered.
* The child thread has not yet started (once it starts it will have a
live reference).
then the heap object will incorrectly appear to be leaked.
This bug is covered by the `lsan/TestCases/leak_check_before_thread_started.cpp` test case.
In b029c5101f ASan was changed to block
in `pthread_create()` until the child thread starts so that `arg` is
kept alive for the purposes of leaking check.
While this change "works" its problematic due to the performance
problems it causes. The change is also completely unnecessary if leak
checking is disabled (via detect_leaks runtime option or
CAN_SANITIZE_LEAKS compile time config).
This patch does two things:
1. Takes a different approach to solving the leak false positive by
making LSan's leak checking mechanism treat the `arg` pointer of
created but not started threads as reachable. This is done by
implementing the `ForEachRegisteredThreadContextCb` callback for
ASan.
2. Removes the blocking behaviour in the ASan `pthread_create`
interceptor.
rdar://problem/63537240
Differential Revision: https://reviews.llvm.org/D95184
This mechanism is intended to provide a way to treat the `arg` pointer
of a created (but not yet started) thread as reachable. In future
patches this will be implemented in `GetAdditionalThreadContextPtrs`.
A separate implementation of `GetAdditionalThreadContextPtrs` exists
for ASan and LSan runtimes because they need to be implemented
differently in future patches.
rdar://problem/63537240
Differential Revision: https://reviews.llvm.org/D95183
kAllocBegMagic should be enough.
kAllocBegMagic is already set for the Secondary allocations.
kAllocBegMagic is good enough for the Primary, but it's even safer for
the Secondary allocator as all allocated block are from mmap.
Depends on D87646.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87647
Make it atomic.
Wrap it into class.
Set it late after chunk is initialized.
Reset it soon when the chunk is still valid.
Depends on D87645.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87646
Before D87643 they where used to optimize UsedSize(). Which was
called frequently from leak scanner.
It was also used for calls from QuarantineCallback
but we have heavy get_allocator().Deallocate call there anyway.
Depends on D87643.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87644
Now we have enough space in the ChunkHeader.
45 bit is enough for kMaxAllowedMallocSize.
Depends on D87642.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87643
The check that the pointer inside of the user part of the chunk does not
adds any value, but it's the last user of AddrIsInside.
I'd like to simplify AsanChunk in followup patches.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87642
If user thread is in the allocator, the allocator
may have no pointer into future user's part of
the allocated block. AddrIsInside ignores such
pointers and lsan reports a false memory leak.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87552
Update both thread and stack.
Update thread and stack as atomic operation.
Keep all 32bit of TID as now we have enough bits.
Depends on D87135.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87217
CHUNK_ALLOCATED. CHUNK_QUARANTINE are only states
which make AsanChunk useful for GetAsanChunk callers.
In either case member of AsanChunk are not useful.
Fix few cases which didn't expect nullptr. Most of the callers are already
expects nullptr.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87135
Fixes https://github.com/google/sanitizers/issues/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
There are no know bugs related to this, still it may fix some latent ones.
Main concerns with preexisting code:
1. Inconsistent atomic/non-atomic access to the same field.
2. Assumption that bitfield chunk_state is always the first byte without
even taking into account endianness.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D86917
There are no know bugs related to this, still it may fix some latent ones.
Main concerns with preexisting code:
1. Inconsistent atomic/non-atomic access to the same field.
2. Assumption that bitfield chunk_state is always the first byte without
even taking into account endianness.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D86917
There are no know bugs related to this, still it may fix some latent ones.
Main concerns with preexisting code:
1. Inconsistent atomic/non-atomic access to the same field.
2. Assumption that bitfield chunk_state is always the first byte without
even taking into account endianness.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D86917
Summary:
Sometimes an allocation stack trace is not very informative. Provide a
way to replace it with a stack trace of the user's choice.
Reviewers: pcc, kcc
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69208
Summary:
The flag allows the user to specify a maximum allocation size that the
sanitizers will honor. Any larger allocations will return nullptr or
crash depending on allocator_may_return_null.
Reviewers: kcc, eugenis
Reviewed By: kcc, eugenis
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69576
Vitaly Buka