| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
quite amusing on some programs:
RSS 9152 MB: shadow:2456 meta:1736 file:454 mmap:3442 trace:196 heap:866 other:0 stacks=176[1065994] nthr=157/159
...
RSS 30192 MB: shadow:613 meta:5550 file:1839 mmap:20487 trace:212 heap:1489 other:0 stacks=12870[1599445] nthr=162/165
...
RSS 42232 MB: shadow:599 meta:8199 file:2304 mmap:29420 trace:213 heap:1494 other:0 stacks=17794[1690645] nthr=162/165
llvm-svn: 218988
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On some tests we see that signals are not delivered
when a thread is blocked in epoll_wait. The hypothesis
is that the signal is delivered right before epoll_wait
call. The signal is queued as in_blocking_func is not set
yet, and then the thread just blocks in epoll_wait forever.
So double check pending signals *after* setting
in_blocking_func. This way we either queue a signal
and handle it in the beginning of a blocking func,
or process the signal synchronously if it's delivered
when in_blocking_func is set.
llvm-svn: 218070
|
|
|
|
|
|
|
|
|
|
| |
I don't remember that crash on mmap in internal allocator
ever yielded anything useful, only crashes in rare wierd untested situations.
One of the reasons for crash was to catch if tsan starts allocating
clocks using mmap. Tsan does not allocate clocks using internal_alloc anymore.
Solve it once and for all by allowing mmaps.
llvm-svn: 217929
|
|
|
|
|
|
| |
Fixes https://code.google.com/p/thread-sanitizer/issues/detail?id=75
llvm-svn: 217908
|
|
|
|
|
|
| |
Most real programs setup much more than 1024 callbacks.
llvm-svn: 217713
|
|
|
|
| |
llvm-svn: 217559
|
|
|
|
|
|
|
|
|
| |
We may as well just use Symbolizer::GetOrInit() in all the cases.
Don't call Symbolizer::Get() early in tools initialization: these days
it doesn't do any important setup work, and we may as well create the
symbolizer the first time it's actually needed.
llvm-svn: 217558
|
|
|
|
|
|
|
| |
The second part of the fix of
https://code.google.com/p/thread-sanitizer/issues/detail?id=71
llvm-svn: 217031
|
|
|
|
|
|
| |
Fixes issue https://code.google.com/p/thread-sanitizer/issues/detail?id=74
llvm-svn: 216906
|
|
|
|
|
|
|
|
|
|
|
| |
There interceptors do not seem to be strictly necessary for tsan.
But we see cases where the interceptors consume 70% of execution time.
Memory blocks passed to fgetgrent_r are "written to" by tsan several times.
First, there is some recursion (getgrnam_r calls fgetgrent_r), and each
function "writes to" the buffer. Then, the same memory is "written to"
twice, first as buf and then as pwbufp (both of them refer to the same addresses).
llvm-svn: 216904
|
|
|
|
|
|
|
| |
Fixes issue
https://code.google.com/p/thread-sanitizer/issues/detail?id=71
llvm-svn: 216903
|
|
|
|
|
|
| |
See http://reviews.llvm.org/D4794
llvm-svn: 216900
|
|
|
|
|
|
|
| |
Users expect synchronization between sigaction and arrival
of the signal. See the test for details.
llvm-svn: 216878
|
|
|
|
|
|
| |
functionality change intended
llvm-svn: 216407
|
|
|
|
|
|
| |
accidentally enabled in r215479. Add a test.
llvm-svn: 215763
|
|
|
|
|
|
| |
It was possimitically handling an aligned 8-byte access as 2 4-byte accesses.
llvm-svn: 215546
|
|
|
|
|
|
| |
sanitizer_common
llvm-svn: 215481
|
|
|
|
| |
llvm-svn: 215479
|
|
|
|
|
|
|
|
| |
favor of
a unified interface in <sanitizer/allocator_interface.h>.
llvm-svn: 215469
|
|
|
|
|
|
|
|
|
|
| |
Vector clocks is the most actively allocated object in tsan runtime.
Current internal allocator is not scalable enough to handle allocation
of clocks in scalable way (too small caches). This changes transforms
clocks to 2-level array with 512-byte blocks. Since all blocks are of
the same size, it's possible to cache them more efficiently in per-thread caches.
llvm-svn: 214912
|
|
|
|
|
|
|
| |
Suppression context might be used in multiple sanitizers working
simultaneously (e.g. LSan and UBSan) and not knowing about each other.
llvm-svn: 214831
|
|
|
|
|
|
|
| |
Fixes build failure on an old system:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-centos-6.5/builds/7555/steps/build/logs/stdio
llvm-svn: 214394
|
|
|
|
|
|
| |
Remove corresponding bits from LSan and TSan runtimes. No functionality change.
llvm-svn: 214344
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 214343
|
|
|
|
|
|
|
|
|
|
| |
sanitizer_common.
Convert TSan and LSan to the new interface. More changes will follow:
1) "suppressions" should become a common runtime flag.
2) Code for parsing suppressions file should be moved to SuppressionContext::Init().
llvm-svn: 214334
|
|
|
|
| |
llvm-svn: 214082
|
|
|
|
|
|
| |
see the comment for justification
llvm-svn: 214030
|
|
|
|
|
|
|
|
|
|
|
| |
Get rid of Symbolizer::Init(path_to_external) in favor of
thread-safe Symbolizer::GetOrInit(), and use the latter version
everywhere. Implicitly depend on the value of external_symbolizer_path
runtime flag instead of passing it around manually.
No functionality change.
llvm-svn: 214005
|
|
|
|
|
|
| |
Now that it become faster, it's OK to query it every 100ms again.
llvm-svn: 213943
|
|
|
|
|
|
|
|
| |
It is currently broken because it reads a wrong value from profile (heap instead of total).
Also make it faster by reading /proc/self/statm. Reading of /proc/self/smaps
can consume more than 50% of time on beefy apps if done every 100ms.
llvm-svn: 213942
|
|
|
|
| |
llvm-svn: 213384
|
|
|
|
| |
llvm-svn: 213382
|
|
|
|
|
|
| |
There is now a more common functionality in the form of called_from_lib suppressions.
llvm-svn: 213057
|
|
|
|
|
|
| |
There are no known usages anymore, so one less thing to support.
llvm-svn: 213056
|
|
|
|
|
|
| |
don't reset s->addr as well
llvm-svn: 212565
|
|
|
|
|
|
| |
They cause "check-tsan" command to hang. Details in r212532 review thread.
llvm-svn: 212562
|
|
|
|
|
|
| |
JVM actually moves memory between overlapping ranges.
llvm-svn: 212560
|
|
|
|
|
|
|
|
| |
The tsan's deadlock detector has been used in Chromium for a while;
it found a few real bugs and reported no false positives.
So, it's time to give it a bit more exposure.
llvm-svn: 212533
|
|
|
|
|
|
|
| |
idx0 is not updated in the branch,
so if we take that branch idx0 will stay updated forever
llvm-svn: 212532
|
|
|
|
|
|
|
|
|
| |
The bug happens in the following case:
Mutex is located at heap block beginning,
when we call MutexDestroy, s->next is set to 0,
so free can't find the MBlock related to the block.
llvm-svn: 212531
|
|
|
|
|
|
| |
(https://code.google.com/p/thread-sanitizer/issues/detail?id=67)
llvm-svn: 212529
|
|
|
|
|
|
| |
deadlocks when reporting bad unlock
llvm-svn: 212526
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce new public header <sanitizer/allocator_interface.h> and a set
of functions __sanitizer_get_ownership(), __sanitizer_malloc_hook() etc.
that will eventually replace their tool-specific equivalents
(__asan_get_ownership(), __msan_get_ownership() etc.). Tool-specific
functions are now deprecated and implemented as stubs redirecting
to __sanitizer_ versions (which are implemented differently in each tool).
Replace all uses of __xsan_ versions with __sanitizer_ versions in unit
and lit tests.
llvm-svn: 212469
|
|
|
|
| |
llvm-svn: 212322
|
|
|
|
|
|
|
|
|
|
|
| |
user_alloc_usable_size.
The former used to crash with a null deref if it was given a not owned pointer,
while the latter returned 0. Now they both return 0. This is still not the best possible
behavior: it is better to print an error report with a stack trace, pointing
to the error in user code, as we do in ASan.
llvm-svn: 212112
|
|
|
|
|
|
|
| |
It is required to prevent false positives between object ctor and finalizer,
as otherwise they look completely unsynchronized.
llvm-svn: 211829
|
|
|
|
| |
llvm-svn: 211429
|
|
|
|
| |
llvm-svn: 211418
|
|
|
|
| |
llvm-svn: 211389
|
|
|
|
| |
llvm-svn: 211386
|