This is an archive of the discontinued LLVM Phabricator instance.

Add a flag to force tsan's background thread
ClosedPublic

Authored by fowles on Dec 14 2021, 1:29 PM.

Diff Detail

Event Timeline

fowles requested review of this revision.Dec 14 2021, 1:29 PM
fowles created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptDec 14 2021, 1:29 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
vitalybuka added inline comments.
compiler-rt/lib/tsan/rtl/tsan_rtl.cpp
690

Can we avoid the flag?

Is pthread already initialized here? Maybe safer later, with global constructor.

vitalybuka added inline comments.Dec 14 2021, 6:26 PM
compiler-rt/lib/tsan/rtl/tsan_rtl.cpp
690

Can we avoid the flag?

I see another thread, @dvyukov asked for the flag.

Is pthread already initialized here? Maybe safer later, with global constructor.

for context: D55887 fixed Android and NetBSD issue in Asan

fowles added inline comments.Dec 14 2021, 9:45 PM
compiler-rt/lib/tsan/rtl/tsan_rtl.cpp
690

As mentioned, the flag was explicitly requested elsewhere. I am open to moving the call to another location if you can suggest something better. I will observe that the test does pass...

dvyukov added inline comments.Dec 14 2021, 10:52 PM
compiler-rt/lib/tsan/rtl/tsan_rtl.cpp
690

Yes, I don't know, if enable it by default it will probably break something somewhere out there. I am not a fan of flags myself, but I think it will be safer with a flag.

Vitaly, do you have any other comments? Or should I land this?

dvyukov accepted this revision.Dec 14 2021, 10:52 PM
This revision is now accepted and ready to land.Dec 14 2021, 10:52 PM

I don't have commit privs, so please land it when you both agree.

vitalybuka accepted this revision.Dec 14 2021, 10:59 PM
vitalybuka added inline comments.
compiler-rt/lib/tsan/rtl/tsan_rtl.cpp
690

No other comments. If D55887 is not concern, then LGTM

dvyukov added inline comments.Dec 15 2021, 9:19 AM
compiler-rt/lib/tsan/rtl/tsan_rtl.cpp
690

I guess D55887 is a concern if somebody uses this on NetBSD... and, well, tests will do it, so I guess they will fail.
I think we need to move creation of the thread to a global ctor as D55887 does.

fowles added inline comments.Dec 15 2021, 1:57 PM
compiler-rt/lib/tsan/rtl/tsan_rtl.cpp
690

When I make the suggested change to use a global I get a crash

/usr/local/google/home/kfm/dev/llvm/compiler-rt/lib/tsan/rtl/../go/buildgo.sh: line 213: 1320312 Segmentation fault (core dumped) $DIR/test 2> /dev/null
make[3]: * [projects/compiler-rt/lib/tsan/rtl/CMakeFiles/GotsanRuntimeCheck.dir/build.make:72: projects/compiler-rt/lib/tsan/rtl/CMakeFiles/GotsanRuntimeCheck] Error 139
make[2]:
* [CMakeFiles/Makefile2:39112: projects/compiler-rt/lib/tsan/rtl/CMakeFiles/GotsanRuntimeCheck.dir/all] Error 2

dvyukov added inline comments.Dec 15 2021, 10:40 PM
compiler-rt/lib/tsan/rtl/tsan_rtl.cpp
690

Out it under #if !SANITIZER_GO. Go does not use the background thread.

fowles updated this revision to Diff 394866.Dec 16 2021, 7:10 AM

Updating D115759: Summary: Add a flag to force tsan's background thread

fowles marked 6 inline comments as done.Dec 16 2021, 7:11 AM

Code updated, PTAL

vitalybuka accepted this revision.Dec 16 2021, 9:55 AM
vitalybuka added inline comments.Dec 16 2021, 9:58 AM
compiler-rt/test/tsan/force_background_thread.cpp
3

maybe we can add VPrintf into static void *BackgroundThread(void *arg) {
so we can observer it from the test with verbosity=1, and for future debugging.

dvyukov added inline comments.Dec 16 2021, 10:46 AM
compiler-rt/test/tsan/force_background_thread.cpp
3

It has several VReport(1). One can be triggered if flush_memory_ms is set as well.

vitalybuka added inline comments.Dec 16 2021, 10:52 AM
compiler-rt/test/tsan/force_background_thread.cpp
3

if it's easy to trigger it would be nice to be used in this test to make FileCheck see a difference force_background_thread=0 vs force_background_thread=1

vitalybuka added inline comments.Dec 16 2021, 10:55 AM
compiler-rt/lib/tsan/rtl/tsan_flags.inc
49
vitalybuka added inline comments.Dec 16 2021, 11:32 AM
compiler-rt/test/tsan/force_background_thread.cpp
3

@dvyukov if it's OK to you I can update and land the patch?

// RUN: %clangxx_tsan -O1 %s -o %t
// RUN: %deflake %env_tsan_opts=force_background_thread=0:verbosity=1:memory_limit_mb=1000 %run %t 2>&1 | FileCheck %s --implicit-check-not "memory flush check"
// RUN: %deflake %env_tsan_opts=force_background_thread=1:verbosity=1:memory_limit_mb=1000 %run %t 2>&1 | FileCheck %s --check-prefixes=CHECK,THREAD
// RUN: %deflake %env_tsan_opts=force_background_thread=0:verbosity=1:memory_limit_mb=1000 %run %t 1 2>&1 | FileCheck %s --check-prefixes=CHECK,THREAD
#include "test.h"

void *Thread(void *a) {
  return nullptr;
}

int main(int argc, char* argv[]) {
  if (argc > 1) {
   pthread_t t;
   pthread_create(&t, nullptr, Thread, nullptr);
   void* p;
   pthread_join(t, &p);
  }
  sleep(3);
  return 1;
}

// CHECK: Running under ThreadSanitizer
// THREAD: ThreadSanitizer: memory flush check
dvyukov added inline comments.Dec 16 2021, 11:33 AM
compiler-rt/test/tsan/force_background_thread.cpp
3

if it's OK to you I can update and land the patch?

Please do.

Suppress -Wglobal-constructors
add VPrint checks in test

vitalybuka retitled this revision from Summary: Add a flag to force tsan's background thread to Add a flag to force tsan's background thread.Dec 16 2021, 11:46 AM
This revision was landed with ongoing or failed builds.Dec 16 2021, 11:47 AM
This revision was automatically updated to reflect the committed changes.

@vitalybuka This change caused a regression on Darwin CI for tsan -,
This is the CI job: https://green.lab.llvm.org/green/job/clang-stage1-RA, and the build: https://green.lab.llvm.org/green/job/clang-stage1-RA/26354/
ThreadSanitizer-x86_64.Darwin.dlopen.cpp is now failing because the initializer that you added runs before flags is initialized when it's being dlopened . Could you take a look at this issue?

yln added a subscriber: yln.Dec 20 2021, 2:36 PM

@vitalybuka This change caused a regression on Darwin CI for tsan -,
This is the CI job: https://green.lab.llvm.org/green/job/clang-stage1-RA, and the build: https://green.lab.llvm.org/green/job/clang-stage1-RA/26354/
ThreadSanitizer-x86_64.Darwin.dlopen.cpp is now failing because the initializer that you added runs before flags is initialized when it's being dlopened . Could you take a look at this issue?

More context: it happens when we dlopen() uninstrumented code from instrumented code. In that case we always exit, but we used to print a useful error message. Now we just crash because ctx is still nullptr, when we ask flags()->force_background_thread from the global initializer.
Failing test: compiler-rt/test/tsan/Darwin/dlopen.cpp

I am not sure if this is a Darwin-specific issue or if it's just that we don't have an analogous test for Linux. @vitalybuka, can you check?

In any case, I am fine with just #ifdefing out the global initializer (i.e., not supporting the flag on Darwin) and going with whatever the default is. I think we are happy with both the current or "eager background thread" creation. It's just that accessing the flag value from the global initializer doesn't work in all cases.

@vitalybuka This change caused a regression on Darwin CI for tsan -,
This is the CI job: https://green.lab.llvm.org/green/job/clang-stage1-RA, and the build: https://green.lab.llvm.org/green/job/clang-stage1-RA/26354/
ThreadSanitizer-x86_64.Darwin.dlopen.cpp is now failing because the initializer that you added runs before flags is initialized when it's being dlopened . Could you take a look at this issue?

More context: it happens when we dlopen() uninstrumented code from instrumented code. In that case we always exit, but we used to print a useful error message. Now we just crash because ctx is still nullptr, when we ask flags()->force_background_thread from the global initializer.
Failing test: compiler-rt/test/tsan/Darwin/dlopen.cpp

I am not sure if this is a Darwin-specific issue or if it's just that we don't have an analogous test for Linux. @vitalybuka, can you check?

In any case, I am fine with just #ifdefing out the global initializer (i.e., not supporting the flag on Darwin) and going with whatever the default is. I think we are happy with both the current or "eager background thread" creation. It's just that accessing the flag value from the global initializer doesn't work in all cases.

looking

@vitalybuka This change caused a regression on Darwin CI for tsan -,

Now it fails in the force_background_thread.cpp itself, which I disabled on Darwin. Not sure what is the meaning of this, I have no access to OSX at the moment to debug.
I suspect pthread is not available yet.
https://green.lab.llvm.org/green/job/clang-stage1-RA/26463/consoleFull#946751328254eaf0-7326-4999-85b0-388101f2d404