According to the logs and local debugging there were two issues:
1) tsan tests listed libc++.a before the source file. That's usually
ok for shared libraries, but the linker will not add symbols from
a static library unless needed at that time. As a result the tests
that rely upon symbols from the library (and not only include the
headers) had undefined references.
To solve this I'm adding a new substitution %link_libcxx_tsan which
expands to libc++.a if available.
2) The target Fuzzer-x86_64-Test linked in SANITIZER_TEST_CXX_LIBRARIES
which defaults to -lstdc++. This resulted in error messages like
hidden symbol '_ZdlPv' is not defined locally
hidden symbol '_Znwm' is not defined locally
when using GNU gold (ld.bfd and lld are fine). Removing the linkage
is fine because we build a custom libc++ for that purpose.
llvm-svn: 354231
Another attempt at fixing tsan_invisible_barrier.
Current implementation causes:
https://llvm.org/bugs/show_bug.cgi?id=25643
There were several unsuccessful iterations for this functionality:
Initially it was implemented in user code using REAL(pthread_barrier_wait). But pthread_barrier_wait is not supported on MacOS. Futexes are linux-specific for this matter.
Then we switched to atomics+usleep(10). But usleep produced parasitic "as-if synchronized via sleep" messages in reports which failed some output tests.
Then we switched to atomics+sched_yield. But this produced tons of tsan- visible events, which lead to "failed to restore stack trace" failures.
Move implementation into runtime and use internal_sched_yield in the wait loop.
This way tsan should see no events from the barrier, so not trace overflows and
no "as-if synchronized via sleep" messages.
llvm-svn: 255030
Even sleep(1) lead to episodical flakes on some machines.
Use an invisible by tsan barrier to enforce required execution order instead.
This makes the tests deterministic and faster.
llvm-svn: 226659
Add a script that is used to deflake inherently flaky tsan tests.
It is invoked from lit tests as:
%deflake %run %t
The script runs the target program up to 10 times,
until it produces a tsan warning.
llvm-svn: 209898
Jonas Hahnfeld