With unquoted ${CMAKE_CXX_FLAGS}, the REGEX fails when it's empty:
```CMake Error at lib/scudo/standalone/CMakeLists.txt:14 (string):
string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
command.```
Change 636428c727 enabled BlockingRegion hooks for pthread_once().
Unfortunately this seems to cause crashes on Mac OS X which uses
pthread_once() from locations that seem to result in crashes:
| ThreadSanitizer:DEADLYSIGNAL
| ==31465==ERROR: ThreadSanitizer: stack-overflow on address 0x7ffee73fffd8 (pc 0x00010807fd2a bp 0x7ffee7400050 sp 0x7ffee73fffb0 T93815)
| #0 __tsan::MetaMap::GetSync(__tsan::ThreadState*, unsigned long, unsigned long, bool, bool) tsan_sync.cpp:195 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x78d2a)
| #1 __tsan::MutexPreLock(__tsan::ThreadState*, unsigned long, unsigned long, unsigned int) tsan_rtl_mutex.cpp:143 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x6cefc)
| #2 wrap_pthread_mutex_lock sanitizer_common_interceptors.inc:4240 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x3dae0)
| #3 flockfile <null>:2 (libsystem_c.dylib:x86_64+0x38a69)
| #4 puts <null>:2 (libsystem_c.dylib:x86_64+0x3f69b)
| #5 wrap_puts sanitizer_common_interceptors.inc (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x34d83)
| #6 __tsan::OnPotentiallyBlockingRegionBegin() cxa_guard_acquire.cpp:8 (foo:x86_64+0x100000e48)
| #7 wrap_pthread_once tsan_interceptors_posix.cpp:1512 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x2f6e6)
From the stack trace it can be seen that the caller is unknown, and the
resulting stack-overflow seems to indicate that whoever the caller is
does not have enough stack space or otherwise is running in a limited
environment not yet ready for full instrumentation.
Fix it by reverting behaviour on Mac OS X to not call BlockingRegion
hooks from pthread_once().
Reported-by: azharudd
Reviewed By: glider
Differential Revision: https://reviews.llvm.org/D108305
The shadow for a short granule is stored in the last byte of the
granule. Currently, if there's a tail-overwrite report (a
buffer-overflow-write in uninstrumented code), we report the shadow byte
as a mismatch against the magic.
Fix this bug by slapping the shadow into the expected value. This also
makes sure that if the uninstrumented WRITE does clobber the shadow
byte, it reports the shadow was actually clobbered as well.
Reviewed By: eugenis, fmayer
Differential Revision: https://reviews.llvm.org/D107938
D104556 change the CountersPtr to be relative, however, it did not
update the pointer initialization in __llvm_profile_register_function,
so the platform (eg:AIX) that use __llvm_profile_register_function is now totaly
broken, any PGO code will SEGV.
This patch update the code to reflect that the Data->CountersPtr is now
relative.
Reviewed By: MaskRay, davidxl
Differential Revision: https://reviews.llvm.org/D108304
According to comments at https://reviews.llvm.org/D107911,
Trace.MemoryAccessSize fails on Mac buildbots.
Because this test is newly introduced, and is the only user of the code
added in that patch, disable the test on Mac till the problem is
resolved.
Differential Revision: https://reviews.llvm.org/D108294
This change adds support to ORCv2 and the Orc runtime library for static
initializers, C++ static destructors, and exception handler registration for
ELF-based platforms, at present Linux and FreeBSD on x86_64. It is based on the
MachO platform and runtime support introduced in bb5f97e3ad.
Patch by Peter Housel. Thanks very much Peter!
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D108081
Before this change we were locking the StackDepot in the fork()
interceptor. This results in a deadlock when allocator functions are
used in a pthread_atfork() callback.
Instead, set up a pthread_atfork() callback at init that locks/unlocks
both StackDepot and the allocator. Since our callback is set up very
early, the pre-fork callback is executed late, and both post-fork ones
are executed early, which works perfect for us.
Differential Revision: https://reviews.llvm.org/D108063
This reverts commit 797fe59e6b.
The use of "EventType type : 3" is replicated for all Event structs and
therefore was still present. As a result this still caused failures on
older GCCs (9.2 or 8.3 or earlier).
The particular bot that was failing due to buggy GCC was fixed by
fef39cc472.
Therefore, no reason to keep the workaround around; revert it.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108192
D104248 moved the call to GetThreadStackAndTls to before the
initialization of the ring buffer TLS slot. As a result, if libc
is instrumented we crash in pthread_getattr_np which is called from
__sanitizer::GetThreadStackTopAndBottom.
Fix the problem by moving the stack ring buffer initialization before
the call to InitStackAndTls.
Differential Revision: https://reviews.llvm.org/D108184
Some compilers started complaining about the test:
tsan_trace_test.cpp:128:21: error: missing field 'type' initializer
Fix it by initializing all 5 fields, even though the type field will be
reset in the for loop.
Differential Revision: https://reviews.llvm.org/D108207
This removes the -Werror compilation flag for x64 linux to work around a gcc bug.
GCC 8.3 reports '__tsan::v3::Event::type’ is too small to hold all values of ‘enum class __tsan::v3::EventType’
incorrectly which gets promoted to an error and causes the build to fail.
This is a redo of D108089 that broke some 32-bit builds.
`scudo::uptr` was defined as an `unsigned long` on 32-b platform,
while a `uintptr_t` is usually defined as an `unsigned int`.
This worked, this was not consistent, particularly with regard to
format string specifiers.
As suggested by Vitaly, since we are including `stdint.h`, define
the internal scudo integer types to those.
Differential Revision: https://reviews.llvm.org/D108152
This patch adds static keyword to internal functions that write
binary id to restrict visibility to the file that they are declared.
Differential Revision: https://reviews.llvm.org/D108154
`scudo::uptr` was defined as an `unsigned long` on 32-b platform,
while a `uintptr_t` is usually defined as an `unsigned int`.
This worked, this was not consistent, particularly with regard to
format string specifiers.
As suggested by Vitaly, since we are including `stdint.h`, define
the internal `scudo` integer types to those.
Differential Revision: https://reviews.llvm.org/D108089
At least when compiling with gcc, this is not supported and will
result in errors when linking against the profiler runtime. Only
use the pragma comment linker based code with MSVC, but not with
a mingw toolchain. This also undoes D107620, which shouldn't be
relevant anymore.
Differential Revision: https://reviews.llvm.org/D108095
Add structures for the new trace format,
functions that serialize and add events to the trace
and trace replaying logic.
Differential Revision: https://reviews.llvm.org/D107911
Currently we only support %z and %ll width modifiers,
but surprisingly not %l. This makes it impossible to print longs
(sizeof(long) not necessary equal to sizeof(size_t)).
We had some printf's that printed longs with %zu,
but that's wrong and now with __attribute__((format)) in place
they are flagged by compiler. So we either have a choice of
doing static_cast<uptr>(long) everywhere or add %l.
Adding %l looks better, that's a standard modifier.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108066
We use kShadowCnt (number of shadow cells per application granule)
when computing shadow, but it's wrong. We need the ratio
between shadow and app memory (how much shadow is larger than app memory),
which is kShadowMultiplier.
Currently both are equal to 4, so it works fine.
Use the correct constant.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D108033
Move __attribute__((format)) to the function declarations in the header file.
It's almost pointless in the source file.
But disable the warning with -Wno-format for now
since there is a number of existing warnings.
Depends on D107984.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108014
This fixes just a few of the warnings.
Ubsan is not completely clean yet,
but these somehow pop up while I was
fixing other sanitizers.
Depends on D107983.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107984
Enable -Wformat in sanitizer_common now that it's
cleaned up from existing warnings.
But disable it in all sanitizers for now since
they are not cleaned up yet, but inherit sanitizer_common CFLAGS.
Depends on D107980.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107981
No point in declaring variables separately before use.
Depends on D107979.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108015
This reverts commits
"sanitizer_common: support printing __m128i type"
and "[sanitizer] Fix VSNPrintf %V on Windows".
Unfortunately, custom "%V" is inherently incompatible with -Wformat,
it produces both:
warning: invalid conversion specifier 'V' [-Wformat-invalid-specifier]
warning: data argument not used by format string [-Wformat-extra-args]
If we disable both of these warnings we lose lots of useful warnings as well.
Depends on D107978.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107979
The attribute should be in the header on declaration.
It's almost pointless in the source file.
Depends on D107977.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107978
Brian Cain