Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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. |
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... |
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? |
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 |
compiler-rt/lib/tsan/rtl/tsan_rtl.cpp | ||
---|---|---|
690 | Out it under #if !SANITIZER_GO. Go does not use the background thread. |
compiler-rt/test/tsan/force_background_thread.cpp | ||
---|---|---|
3 | maybe we can add VPrintf into static void *BackgroundThread(void *arg) { |
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. |
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 |
compiler-rt/lib/tsan/rtl/tsan_flags.inc | ||
---|---|---|
49 |
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 |
compiler-rt/test/tsan/force_background_thread.cpp | ||
---|---|---|
3 |
Please do. |
@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.
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