[PATCH] D91620: [compiler-rt][test] Heed COMPILER_RT_DEBUG when compiling unittests
Rainer Orth via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Oct 14 05:34:41 PDT 2022
ro added a comment.
In D91620#3851164 <https://reviews.llvm.org/D91620#3851164>, @vitalybuka wrote:
>> Please disregard this. It was something wrong with my setup.
>
> So I applied the patch on the actual bot and still see tsan go timeouts.
I hadn't seen anything like this, but investgation led me down a rathole:
- At first I thought this was because my Linux/x86_64 test system had neither `go` nor `gccgo` installed. However, adding `go` didn't make a difference in test results.
- Looking for TSan Go tests initially found nothing. Later, I stumbled across `buildgo.sh`, which is a odd beast in various ways.
- It builds the test behind the back of the build system, so `ninja -v` shows nothing.
- It also runs the test outside of the testsuite (`lit`) and produces no test results (`PASS`/`FAIL`/`UNSUPPORTED`), so the test doesn't show u p in the summary.
- The ninja `check-all` output shows
[295/1379] Checking TSan Go runtime...
/vol/llvm/src/llvm-project/local/compiler-rt/lib/tsan/rtl/../go/buildgo.sh: 62: [: unexpected operator
- `buildgo.sh` uses `==` which is unportable, as documented e.g. in `bash(1)`. Ubuntu 20/04 `/bin/sh` is `dash`, which doesn't support it. In the same place, it refers to a variable `GOAMD64` which is never set anywhere AFAICT.
Whatever the case, even if run manually with `bash`, succeeds for me, no timeout or anything.
> Maybe we go incrementally with -O0 -> -O1 in this patch? And if needed figure out -O0 in follow up.
In all my attempts, `-O1` builds were useless for debugging because so many variables were optimized away. However, if that's a way to get the bulk of the patch in and only need a one-byte change to get debuggable output, that's ok, I guess.
However, speaking of timeouts there are four instances of the same issue I see on `x86_64-pc-linux-gnu`: those tests just hang and have to be killed manually. The test summary just shows
ThreadSanitizer-Unit :: unit/./TsanUnitTest-x86_64-Test/31/41
ThreadSanitizer-Unit :: unit/./TsanUnitTest-x86_64-Test/32/41
ThreadSanitizer-Unit :: unit/./TsanUnitTest-x86_64-Test/33/41
ThreadSanitizer-Unit :: unit/./TsanUnitTest-x86_64-Test/34/41
Here gtest sharding is raising its ugly head again (this feature has only caused problems so far). To investigate, I let `TsanUnitTest-x86_64-Test` list its subtests and ran them one by one. The four failing ones are
Trace.RestoreAccess
Trace.MemoryAccessSize
Trace.RestoreMutexLock
Trace.MultiPart
which all show the same failure mode:
[ RUN ] Trace.MultiPart
ThreadSanitizer: internal deadlock: can't lock Slots under Slots mutex
ThreadSanitizer: internal deadlock: can't lock Slots under Slots mutex
I've augmented my patch to just disable those subtests if `SANITIZER_DEBUG`.
================
Comment at: compiler-rt/test/tsan/Linux/check_memcpy.c:10
+// XFAIL: !compiler-rt-optimized
+
----------------
vitalybuka wrote:
> vitalybuka wrote:
> > I see, XFAIL will run the test. So if it's about timeouts, it will still timeout.
> >
> > Just make it
> > // REQUIRES: compiler-rt-optimized
>
> I see, XFAIL will run the test. So if it's about timeouts, it will still timeout.
>
> Just make it
> // REQUIRES: compiler-rt-optimized
It's not: the test `FAIL`s at `-O0` with
```
/vol/llvm/src/llvm-project/local-debug/compiler-rt/test/tsan/Linux/check_memcpy.c:17:15: error: CHECK-NOT: excluded string found in input
// CHECK-NOT: callq {{.*<(__interceptor_)?mem(cpy|set)>}}
^
<stdin>:47254:24: note: found here
454dc: e8 4f d4 02 00 callq 0x72930 <memset>
^~~~~~~~~~~~~~~~~~~~~~
```
i.e. `memset` isn't inlined unlike at `-O1`. This is to be expected, I think, thus the `XFAIL`.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D91620/new/
https://reviews.llvm.org/D91620
More information about the llvm-commits
mailing list