| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
are usable in plain C
llvm-svn: 206160
|
| |
|
|
|
|
| |
parameter. Also fix a typo found by Tetsuo Kiso
llvm-svn: 206158
|
| |
|
|
|
|
| |
otherwise reports get intermixed
llvm-svn: 206043
|
| |
|
|
|
|
|
| |
the new optimizations break when thread ids gets reused (clocks go backwards)
add the necessary tests as well
llvm-svn: 206035
|
| |
|
|
|
|
|
| |
ocassionally we see races coming from symbolizer interceptors (e.g. memcmp)
reproducible only only on large complex programs
llvm-svn: 206034
|
| |
|
|
| |
llvm-svn: 206030
|
| |
|
|
| |
llvm-svn: 206028
|
| |
|
|
| |
llvm-svn: 205919
|
| |
|
|
| |
llvm-svn: 205852
|
| |
|
|
| |
llvm-svn: 205627
|
| |
|
|
|
|
| |
This reduces .tbss from 109K down to almost nothing.
llvm-svn: 205618
|
| |
|
|
|
|
| |
disable this handler completely; remove a workaround for a bug fixed in glibc
llvm-svn: 205617
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a multi-threaded program calls fork(), TSan ignores all memory accesses
in the child to prevent deadlocks in TSan runtime. This is OK, as child is
probably going to call exec() as soon as possible. However, a rare deadlocks
could be caused by ThreadIgnoreBegin() function itself.
ThreadIgnoreBegin() remembers the current stack trace and puts it into the
StackDepot to report a warning later if a thread exited with ignores enabled.
Using StackDepotPut in a child process is dangerous: it locks a mutex on
a slow path, which could be already locked in a parent process.
The fix is simple: just don't put current stack traces to StackDepot in
ThreadIgnoreBegin() and ThreadIgnoreSyncBegin() functions if we're
running after a multithreaded fork. We will not report any
"thread exited with ignores enabled" errors in this case anyway.
Submitting this without a testcase, as I believe the standalone reproducer
is pretty hard to construct.
llvm-svn: 205534
|
| |
|
|
| |
llvm-svn: 205531
|
| |
|
|
|
|
| |
every call to __asan_init
llvm-svn: 205418
|
| |
|
|
|
|
|
| |
It does not do what it's name says, and what it actually does is hard to
describe, and is not useful at all.
llvm-svn: 205415
|
| |
|
|
|
|
| |
An assert()-like function that checks that a memory range is fully initialized.
llvm-svn: 205413
|
| |
|
|
| |
llvm-svn: 205412
|
| |
|
|
| |
llvm-svn: 205411
|
| |
|
|
| |
llvm-svn: 205410
|
| |
|
|
|
|
| |
fp_t.
llvm-svn: 205344
|
| |
|
|
| |
llvm-svn: 205316
|
| |
|
|
|
|
|
|
| |
From GuanHong Liu.
Differential Revision: http://llvm-reviews.chandlerc.com/D2797
llvm-svn: 205312
|
| |
|
|
| |
llvm-svn: 205311
|
| |
|
|
|
|
| |
Based on http://llvm-reviews.chandlerc.com/D3042 by Yuri Gribov!
llvm-svn: 205308
|
| |
|
|
| |
llvm-svn: 205291
|
| |
|
|
| |
llvm-svn: 205290
|
| |
|
|
|
|
|
|
|
|
| |
Add the test infrastructure for testing lib/profile and a single test.
This initial commit only enables the tests on Darwin, but they'll be
enabled on Linux soon after.
<rdar://problem/16458307>
llvm-svn: 205256
|
| |
|
|
| |
llvm-svn: 205192
|
| |
|
|
|
|
|
|
| |
Soon there will be an option to build compiler-rt parts as shared libraries
on Linux. Extracted from http://llvm-reviews.chandlerc.com/D3042
by Yuri Gribov.
llvm-svn: 205183
|
| |
|
|
| |
llvm-svn: 205175
|
| |
|
|
|
|
| |
over the currently held locks using the array, not the bitvector. Bitvector is not the best data structure to iterate over)
llvm-svn: 205168
|
| |
|
|
| |
llvm-svn: 205006
|
| |
|
|
|
|
|
|
| |
These interceptors require deep unpoisoning of return values.
While at it, we do the same for all other pw/gr interceptors to
reduce dependency on libc implementation details.
llvm-svn: 205004
|
| |
|
|
|
|
|
|
| |
It's hard to write a reliable test for this code because they
work with unpredictable memory locations. But this change should
fix current failures in getpwent() tests on the sanitizer bots.
llvm-svn: 205002
|
| |
|
|
| |
llvm-svn: 205001
|
| |
|
|
| |
llvm-svn: 205000
|
| |
|
|
|
|
|
|
| |
Based on patch from GuanHong Liu.
Differential Revision: http://llvm-reviews.chandlerc.com/D2796
llvm-svn: 204999
|
| |
|
|
| |
llvm-svn: 204994
|
| |
|
|
| |
llvm-svn: 204991
|
| |
|
|
|
|
| |
This should make memset_test pass on Mac.
llvm-svn: 204929
|
| |
|
|
| |
llvm-svn: 204927
|
| |
|
|
| |
llvm-svn: 204926
|
| |
|
|
|
|
| |
functions are used
llvm-svn: 204925
|
| |
|
|
| |
llvm-svn: 204923
|
| |
|
|
| |
llvm-svn: 204897
|
| |
|
|
|
|
|
|
|
|
| |
Expose the number of DFSan labels allocated by adding function dfsan_get_label_count().
Patch by Sam Kerner!
Differential Revision: http://llvm-reviews.chandlerc.com/D3109
llvm-svn: 204854
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The interceptors had code that after macro expansion ended up looking like
extern "C" void memalign()
__attribute__((weak, alias("__interceptor_memalign")));
extern "C" void __interceptor_memalign() {}
extern "C" void __interceptor___libc_memalign()
__attribute__((alias("memalign")));
That is,
* __interceptor_memalign is a function
* memalign is a weak alias to __interceptor_memalign
* __interceptor___libc_memalign is an alias to memalign
Both gcc and clang produce assembly that look like
__interceptor_memalign:
...
.weak memalign
memalign = __interceptor_memalign
.globl __interceptor___libc_memalign
__interceptor___libc_memalign = memalign
What it means in the end is that we have 3 symbols pointing to the
same position in the file, one of which is weak:
8: 0000000000000000 1 FUNC GLOBAL DEFAULT 1
__interceptor_memalign
9: 0000000000000000 1 FUNC WEAK DEFAULT 1 memalign
10: 0000000000000000 1 FUNC GLOBAL DEFAULT 1
__interceptor___libc_memalign
In particular, note that __interceptor___libc_memalign will always
point to __interceptor_memalign, even if we do link in a strong symbol
for memalign. In fact, the above code produces exactly the same binary
as
extern "C" void memalign()
__attribute__((weak, alias("__interceptor_memalign")));
extern "C" void __interceptor_memalign() {}
extern "C" void __interceptor___libc_memalign()
__attribute__((alias("__interceptor_memalign")));
If nothing else, this patch makes it more obvious what is going on.
llvm-svn: 204823
|
| |
|
|
|
|
| |
ReportRace takes the two mutexes in the opposite order
llvm-svn: 204809
|
| |
|
|
|
|
| |
newer gcc inserts memset here
llvm-svn: 204808
|