This removes and replaces usage of a few LowLevelAllocators with a single one
provided by sanitizer_common. Functionally, there should be no difference
between using different allocators vs the same one. This works really well
with D158783 which controls the size of each allocator mmap to significantly
reduce fragmentation.
This doesn't remove them all, mainly the ones used by asan and the flag parser.
Differential Revision: https://reviews.llvm.org/D158786
65536 bytes
The LowLevelAllocator is a helper class used by many sanitizer internals
for anonymously mmaping stuff. The allocator (usually) maps one page at
a time, but this can lead to a lot of fragmentation if the allocator is
heavily used. The flag parser is an example of this where it needs to do
lots of string copying that need to exist for a variable length of time.
This adds a macro for specifying the number of pages the LowLevelAllocator
can make at a time, which locally I've found to significantly help reduce
fragmentation and help run the scudo allocator tests in an asan-instrumented
build on riscv Sv39. This is a static macro rather than a value that could
be provided via an env variable because flag parsing is one of the earliest
consumers of the LowLevelAllocator, so this should be set before its ever used.
Note this will mainly help instances of the LowLevelAllocator that are heavily
used, but instances of the LowLevelAllocator that do a small fixed number
of allocations won't benefit as much from this. This can be alleviated though
if we instead consolidate all of them to one single LowLevelAllocator (D158786).
Differential Revision: https://reviews.llvm.org/D158783
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
This reverts commit 5c27740238007d22f2d0cd0ebe2aaffa90a9c92b.
Reverting due to Windows build issue:
sanitizer_stackdepot.cpp.obj : error LNK2005: "void __cdecl __sanitizer::StackDepotStopBackgroundThread(void)" (?StackDepotStopBackgroundThread@__sanitizer@@YAXXZ) already defined in sanitizer_common_libcdep.cpp.obj
LINK : fatal error LNK1181: cannot open input file 'projects\compiler-rt\lib\asan\CMakeFiles\RTAsan_dynamic.x86_64.dir\asan_rtl_x86_64.S.obj'
According comments on D44404, something like that was the goal.
Reviewed By: morehouse, kstoimenov
Differential Revision: https://reviews.llvm.org/D114991
There is a small chance that the internal allocator is locked
during fork and then the new process is created with locked
internal allocator and any attempts to use it will deadlock.
For example, if detected a suppressed race in the parent during fork
and then another suppressed race after the fork.
This becomes much more likely with the new tsan runtime
as it uses the internal allocator for more things.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D114531
It was introduced in:
9cffc9550b75 tsan: allow to force use of __libc_malloc in sanitizer_common
and used in:
512a18e51819 tsan: add standalone deadlock detector
and later used for Go support.
But now both uses are gone. Nothing defines SANITIZER_USE_MALLOC.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D114514
The internal allocator adds 8-byte header for debugging purposes.
The problem with it is that it's not possible to allocate nicely-sized
objects without a significant overhead. For example, if we allocate
512-byte objects, that will be rounded up to 768 or something.
This logic migrated from tsan where it was added during initial development,
I don't remember that it ever caught anything (we don't do bugs!).
Remove it so that it's possible to allocate nicely-sized objects
without overheads.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D105777
tsan while used by golang's race detector was not working on alpine
linux, since it is using musl-c instead of glibc. Since alpine is very
popular distribution for container deployments, having working race
detector would be nice. This commits adds some ifdefs to get it working.
It fixes https://github.com/golang/go/issues/14481 on golang's issue tracker.
Reviewed-in: https://reviews.llvm.org/D75849
Author: graywolf-at-work (Tomas Volf)
MmapOrDie allocates memory multiple to page size. LowLevelAllocator
should use all that memory for the internal buffer because there are
chances that subsequent requests may be small enough to fit in that
space.
Differential Revision: https://reviews.llvm.org/D71275
See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran
for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done
and manually updated (many) references to renamed files found by that.
llvm-svn: 367463
