[PATCH] D91620: [compiler-rt][test] Heed COMPILER_RT_DEBUG when compiling unittests

[Rainer Orth via Phabricator via llvm-commits]

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