search for: tsan

On Sun, Jul 9, 2017 at 3:50 PM, Nischai Vinesh <nischai.vinesh at gmail.com> wrote: > Hello, > > I tried that as well but there are no tsan warnings thrown at run time, even > though there are data race error! > > The steps I followed: > 1. Generate bitcode using 'clang -emit-llvm' command > 2. Using the 'opt -load ..' command, I instrumented the bitcode file with my > custom pass > 3. Using the com...

I'm unsure why this is failing this week, but when I build for FreeBSD HEAD, I now get a failure to find <stdarg.h>. Very strange. Maybe its missing a -I /usr/include somewhere? [1950/2811] Building CXX object projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan-x86_64.dir/rtl/tsan_interceptors.cc.o FAILED: /usr/bin/CC -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-lo...

I think the code is not getting instrumented with tsan at all. In the 'step 3', when I instrument it using 'opt -tsan ...', it gives a warning "WARNING: You're attempting to print out a bitcode file." I guess this method doesn't instrument the code. Is there any other way I can instrument the code with tsan? On...

...d to reconsider macro replacement again?) Some technical notes/explanations that possibly weren't made clear at the meeting. The current compller-rt patch (on phabricator) is already a pretty minimal set. The only real bit of actual functionality (other than the infrastructure bits to enable TSAN on android/aarch64) is the TLS workaround. i.e. the major pieces for my patch to compiler-rt are: - infrastructure (new definitions, cmake changes etc..) - TLS workaround - pthread_barrier-like interface for tests - disabling of some tests on android-aarch64 My current hypothesis is...

...itry Vyukov <dvyukov at google.com> wrote: > On Tue, Jun 27, 2017 at 4:18 PM, Nischai Vinesh > <nischai.vinesh at gmail.com> wrote: >> Hello, >> >> I have written a custom pass to do some tasks and I want to run this pass on >> a source code file along with TSAN instrumentation. >> >> Steps I followed: >> 1. I compiled the code file with -fsanitize=thread and -emit-llvm to get the >> byte code of the file >> 2. Used opt to run my custom pass on the TSAN instrumented .bc file >> 3. Run the final .bc file using lli with p...

On Tue, Jun 27, 2017 at 4:18 PM, Nischai Vinesh <nischai.vinesh at gmail.com> wrote: > Hello, > > I have written a custom pass to do some tasks and I want to run this pass on > a source code file along with TSAN instrumentation. > > Steps I followed: > 1. I compiled the code file with -fsanitize=thread and -emit-llvm to get the > byte code of the file > 2. Used opt to run my custom pass on the TSAN instrumented .bc file > 3. Run the final .bc file using lli with proper inputs > > T...

Hello, I trying TSAN on Darwin on LLVM itself (sanitizing multi-threaded ThinLTO link). However I see two main issues on my debug build: 1) Statistics: the pre/post increment is not safe, it seems to be acknowledge in the code itself: // FIXME: This function and all those that follow carefully use an // atom...

Hi, I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. TSan already supports pthread_on...

...l end with this: [100%] Running ThreadSanitizer tests -- Testing: 258 tests, 16 threads -- Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. command timed out: 1200 seconds without output, attempting to kill It seems like we'd get a lot more value from this bot if we just disabled the tsan tests, or at whichever tests have the highest deadlock risk. On Thu, May 14, 2015 at 1:08 PM, Kostya Serebryany <kcc at google.com> wrote: > +dvyukov > > On Wed, May 13, 2015 at 11:08 AM, David Blaikie <dblaikie at gmail.com> > wrote: > >> >> >> On Wed...

.../clang-cmake-aarch64-full/builds/902 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/894 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/906 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/902 The timeout happens consistently here: PASS: UBSan-TSan-aarch64 :: TestCases/Misc/enum.cpp (25310 of 25316) PASS: UBSan-TSan-aarch64 :: TestCases/TypeCheck/null.cpp (25311 of 25316) PASS: UBSan-TSan-aarch64 :: TestCases/TypeCheck/vptr-virtual-base-construction.cpp (25312 of 25316) PASS: UBSan-TSan-aarch64 :: TestCases/TypeCheck/vptr-virtual-base.cpp (25...

...empting to kill >> process killed by signal 9 >> program finished with exit code -1 >> elapsedTime=3507.624426 >> >> The annotator should probably include that timeout text in the failing >> step, so that sounds like a bug. >> >> Another issue is that tsan times out sometimes. >> > > Also - how often are the timeouts actually indicative of regressions. > Perhaps we could flag them as "exceptional" results, shown in purple (& > possibly not emailing anyone except the buildbot owner) - rather than red > failures someh...

> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> Hi, >> >> I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. >> >> TSan already s...

...1200 seconds without output, attempting to kill > process killed by signal 9 > program finished with exit code -1 > elapsedTime=3507.624426 > > The annotator should probably include that timeout text in the failing > step, so that sounds like a bug. > > Another issue is that tsan times out sometimes. > Also - how often are the timeouts actually indicative of regressions. Perhaps we could flag them as "exceptional" results, shown in purple (& possibly not emailing anyone except the buildbot owner) - rather than red failures somehow. > Should we be send...

...tils/lit/tests && /usr/bin/cmake -E copy_directory ~/wk/LLVM/llvm/utils/lit/tests ~/wk/LLVM/build_release/utils/lit/tests && /usr/bin/cmake -E copy ~/wk/LLVM/build_release/utils/lit/lit.site.cfg ~/wk/LLVM/build_release/utils/lit/tests [2/4] cd ~/wk/LLVM/llvm/projects/compiler-rt/lib/tsan/go && env "CC=/usr/bin/cc " IN_TMPDIR=1 SILENT=1 ~/wk/LLVM/llvm/projects/compiler-rt/lib/tsan/go/buildgo.sh FAILED: projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck cd ~/wk/LLVM/llvm/projects/compiler-rt/lib/tsan/go && env "CC=/usr/bin/cc " IN_TMPDIR=1...

Alexey, I got mail from one of the tsan buildbots, claiming a breakage in tsan tests. But I cannot see anything on the logs it has for the build. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/17916/steps/run%2064-bit%20tsan%20unit%20tests/logs/stdio Any ideas? Thanks. Diego. ---------- Forwarded message ----------...

...>>> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >>>> Hi, >>>> >>>> I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. >>>> >>>&gt...

...make -E copy_directory ~/wk/LLVM/llvm/utils/lit/tests >> ~/wk/LLVM/build_release/utils/lit/tests && /usr/bin/cmake -E copy >> ~/wk/LLVM/build_release/utils/lit/lit.site.cfg >> ~/wk/LLVM/build_release/utils/lit/tests >> [2/4] cd ~/wk/LLVM/llvm/projects/compiler-rt/lib/tsan/go && env >> "CC=/usr/bin/cc " IN_TMPDIR=1 SILENT=1 >> ~/wk/LLVM/llvm/projects/compiler-rt/lib/tsan/go/buildgo.sh >> FAILED: projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck >> cd ~/wk/LLVM/llvm/projects/compiler-rt/lib/tsan/go && env &gt...

I guess there is lots of stuff that you don't care about besides tsan/go that is built and tested during llvm build, and there is no way to selectively disable each one of that. By design. In the long run we need to fix all failures (please file a proper bug). If you are looking for a temporal workaround, then comment it out. I don't what else to suggest. On Tu...

...if (flag == NOT_INITIALIZED_AT_ALL) { flag = BEING_INITIALIZED; mutex_unlock(mut); func(arg); // <=== user code callback mutex_lock(mut); atomic_store(&flag, FULLY_INITIALIZED, mo_release); // "release" store, but within a compiled dylib, thus invisible to TSan } mutex_unlock(mut); } If thread A is just after the release store, which is invisible to TSan, __tsan_acquire in thread B will have no effect, and the stores from the callback to func(arg) will not be synchronized to thread B. Anyway, I just realized that we can wrap "func" into ou...

...ld have > been refused before any real review was made. > > >> As for the design, there is not much to design upfront, as you >> discover most of the issue only when you hit them (I would not foresee >> them). > > TLS emulation vs proper implementation? Emulation in TSAN or RT or > some other lib? > > TSAN is hardly the place for run-time library calls, RT is a much > better place. Work arounds in LLVM is hardly a good replacement for a > proper implementation in the Android linker. > > All those are design decisions. In the end, RT has already...