trietptm / data-race-test Goto Github PK

Automatically exported from code.google.com/p/data-race-test

Shell 0.97% Makefile 2.55% C 20.42% C++ 75.08% Go 0.17% CMake 0.01% Python 0.56% Scilab 0.04% Batchfile 0.02% Objective-C++ 0.17%

data-race-test's Introduction

Hi there 👋

🔭 I’m currently working on incident response & digital forensics (DFIR), cyber security consulting/blue teaming services, system/internal penetration testing/red teaming.
🌱 I’m currently learning Mathematics for Computer Science and Security Engineering.
👯 I’m looking to collaborate on study/researching state-of-the-art tools, techniques, tactics in binary analysis and reverse engineering.
- Python is my favorite programming language: https://github.com/trietptm?tab=repositories&q=&type=&language=python
- I am honoured to be mentioned in the book "The Beginner's Guide to IDAPython" (https://leanpub.com/IDAPython-Book) and some FireEye Flare-On Challenge Honor Roll pages.
🤔 I’m looking for help with business development in Vietnam.
💬 Ask me about any Cyber Security questions if you need Cyber Security Consulting (securing accounts/systems, system security assessments, cyber-security maturity assessment, suspicious/malicious file examination,...) or have a malware/hacking outbreak and need an incident compromise assessment (how and when a hacker got into your system, what post-exploitation activities they did in your system,...), malware remediation help, securing your systems and digital assets.
📫 How to reach me: +84962797946 (WhatsApp, Viber, Signal), LinkedIn (https://www.linkedin.com/in/trietptm/), Twitter DM (https://twitter.com/MinhTrietPT) or reaching me via our company Facebook page for our reverse engineering online courses: https://www.facebook.com/novasec.vn .

GitHub Stats

data-race-test's People

Contributors

Stargazers

Watchers

data-race-test's Issues

Check tsan output in all tests.

Find a way to specify expected tsan output in test programs.

Original issue reported on code.google.com by [email protected] on 12 Jan 2010 at 2:58

"accessing an invalid lock" warnings below unnamedImageEntryPoint on Windows

Example:
==3760== WARNING: accessing an invalid lock 007D19EC in thread T0
==3760==     #1  unnamedImageEntryPoint C:\Windows\syswow64\RPCRT4.dll
==3760==     #2  NdrUserMarshalMemorySize C:\Windows\syswow64\RPCRT4.dll
==3760==     #3  I_RpcTransConnectionAllocatePacket 
C:\Windows\syswow64\RPCRT4.dll
==3760==     #4  I_RpcTransConnectionAllocatePacket 
C:\Windows\syswow64\RPCRT4.dll
==3760==     #5  RpcBindingFree C:\Windows\syswow64\RPCRT4.dll
==3760==     #6  RegOpenKeyExA C:\Windows\syswow64\ADVAPI32.dll
==3760==     #7  RpcStringBindingComposeW C:\Windows\syswow64\RPCRT4.dll
==3760==     #8  RpcStringBindingComposeW C:\Windows\syswow64\RPCRT4.dll
==3760==     #9  RpcStringBindingComposeW C:\Windows\syswow64\RPCRT4.dll
==3760==     #10 NdrProxyErrorHandler C:\Windows\syswow64\RPCRT4.dll
==3760==     #11 NdrClientCall2 C:\Windows\syswow64\RPCRT4.dll
==3760== WARNING: accessing an invalid lock 007D29BC in thread T0

Probably this is a false report or this is due to missing symbols.

Original issue reported on code.google.com by timurrrr on 24 Aug 2010 at 1:28

Code review request

Please check if my java code is sane

Original issue reported on code.google.com by [email protected] on 22 Jun 2009 at 3:17

(False?) reports on OS X

The bot is red so I'll add some ignores for Mac to make it green with a TODO.

http://build.chromium.org/buildbot/tsan/builders/buildbot-mac/builds/1647/steps/
test_4/logs/stdio

==47044== WARNING: Possible data race during write of size 4 at 0xB0102F10: {{{
==47044==    T10 (locks held: {}):
==47044==     #0  MyThread::ThreadBody(MyThread*) 
unittest/bin/racecheck_unittest-darwin-x86-O0
==47044==     #1  ThreadSanitizerStartThread 
/private/tmp/valgrind.XeMY6i/lib/valgrind/vgpreload_tsan-debug-x86-darwin.so
==47044==   Concurrent read(s) happened at (OR AFTER) these points:
==47044==    T6 (locks held: {}):
==47044==     #0  ??? 
==47044==     #1  _pthread_free_pthread_onstack /usr/lib/libSystem.B.dylib
==47044==     #2  _pthread_exit /usr/lib/libSystem.B.dylib
==47044==     #3  thread_start /usr/lib/libSystem.B.dylib
==47044==    Race verifier data: 0x26285,0xFFFF0260
==47044== }}}
==47044== WARNING: Possible data race during write of size 4 at 0xB038CCBC: {{{
==47044==    T150 (locks held: {}):
==47044==     #0  pthread_lib_enter 
/private/tmp/valgrind.XeMY6i/lib/valgrind/vgpreload_tsan-debug-x86-darwin.so
==47044==     #1  pthread_mutex_lock 
/private/tmp/valgrind.XeMY6i/lib/valgrind/vgpreload_tsan-debug-x86-darwin.so
==47044==     #2  _pthread_cond_wait /usr/lib/libSystem.B.dylib
==47044==     #3  pthread_cond_wait$UNIX2003 /usr/lib/libSystem.B.dylib
==47044==     #4  pthread_cond_wait$* 
/private/tmp/valgrind.XeMY6i/lib/valgrind/vgpreload_tsan-debug-x86-darwin.so
==47044==     #5  Mutex::WaitLoop(Condition) 
unittest/bin/racecheck_unittest-darwin-x86-O0
==47044==     #6  Mutex::LockWhen(Condition) 
unittest/bin/racecheck_unittest-darwin-x86-O0
==47044==     #7  ProducerConsumerQueue::Get() 
unittest/bin/racecheck_unittest-darwin-x86-O0
==47044==     #8  ThreadPool::Worker(void*) 
unittest/bin/racecheck_unittest-darwin-x86-O0
==47044==     #9  MyThread::ThreadBody(MyThread*) 
unittest/bin/racecheck_unittest-darwin-x86-O0
==47044==     #10 ThreadSanitizerStartThread 
/private/tmp/valgrind.XeMY6i/lib/valgrind/vgpreload_tsan-debug-x86-darwin.so
==47044==   Concurrent write(s) happened at (OR AFTER) these points:
==47044==    T143 (locks held: {}):
==47044==     #0  pthread_lib_exit 
/private/tmp/valgrind.XeMY6i/lib/valgrind/vgpreload_tsan-debug-x86-darwin.so
==47044==     #1  pthread_mutex_lock 
/private/tmp/valgrind.XeMY6i/lib/valgrind/vgpreload_tsan-debug-x86-darwin.so
==47044==     #2  _pthread_cond_wait /usr/lib/libSystem.B.dylib
==47044==     #3  pthread_cond_wait$UNIX2003 /usr/lib/libSystem.B.dylib
==47044==     #4  pthread_cond_wait$* 
/private/tmp/valgrind.XeMY6i/lib/valgrind/vgpreload_tsan-debug-x86-darwin.so
==47044==     #5  Mutex::WaitLoop(Condition) 
unittest/bin/racecheck_unittest-darwin-x86-O0
==47044==     #6  Mutex::LockWhen(Condition) 
unittest/bin/racecheck_unittest-darwin-x86-O0
==47044==     #7  ProducerConsumerQueue::Get() 
unittest/bin/racecheck_unittest-darwin-x86-O0
==47044==     #8  ThreadPool::Worker(void*) 
unittest/bin/racecheck_unittest-darwin-x86-O0
==47044==     #9  MyThread::ThreadBody(MyThread*) 
unittest/bin/racecheck_unittest-darwin-x86-O0
==47044==    Race verifier data: 0x20B3DEB8,0x20B3DF8B
==47044== }}}

Original issue reported on code.google.com by timurrrr on 27 May 2010 at 8:17

The second version of the Mac OS patch

Purpose of code changes on this branch:


When reviewing my code changes, please focus on:


After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 1 Jul 2009 at 9:47

ThreadSanitizer misses locking events inside signal handler

"tsan ./racecheck_unittest 155" will produce a false positive because  locking 
events are ignored in signal handler.
This happens if signall arrives while the thread is inside malloc (currently, 
tsan ignores locking events inside 
malloc).

==2786== WARNING: Possible data race during read of size 4 at 0x6401E4: {{{
==2786==    T1 (locks held: {}): 
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
==2786==     #0  test155::SignalHandler(int, siginfo*, void*) 
racecheck_unittest.cc:7080
==2786==     #1  test155::Worker() racecheck_unittest.cc:7105
==2786==     #2  MyThread::ThreadBody(MyThread*) thread_wrappers_pthread.h:325
==2786==     #3  ThreadSanitizerStartThread ts_valgrind_intercepts.c:525
==2786==   Concurrent write(s) happened at (OR AFTER) these points:
==2786==    T0 (locks held: {L132}): 
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
==2786==     #0  test155::SignalHandler(int, siginfo*, void*) 
racecheck_unittest.cc:7080
==2786==     #1  usleep /usr/grte/v1/lib64/libc-2.3.6.so
==2786==     #2  MyThreadArray::Start() racecheck_unittest.cc:336
==2786==     #3  test155::Run() racecheck_unittest.cc:7114
==2786==     #4  Test::Run() racecheck_unittest.cc:156
==2786==     #5  main racecheck_unittest.cc:311
==2786==   Address 0x6401E4 is 0 bytes inside data symbol "_ZN7test1554GLOBE"
==2786==   Locks involved in this report (reporting last lock sites): {L132}
==2786==    L132
==2786==     #0  pthread_mutex_lock ts_valgrind_intercepts.c:772
==2786==     #1  Mutex::Lock() thread_wrappers_pthread.h:131
==2786==     #2  test155::SignalHandler(int, siginfo*, void*) 
racecheck_unittest.cc:7079
==2786==     #3  test155::Worker() racecheck_unittest.cc:7105
==2786==     #4  MyThread::ThreadBody(MyThread*) thread_wrappers_pthread.h:325
==2786==     #5  ThreadSanitizerStartThread ts_valgrind_intercepts.c:525
==2786== }}}

Original issue reported on code.google.com by [email protected] on 16 Dec 2009 at 4:02

Make self-contained TSan work on any Linux

We need to have one binary working on Linux 32-bit, Linux 64-bit and Linux 
64-bit running 32-bit app

Original issue reported on code.google.com by timurrrr on 24 Feb 2010 at 3:48

TSan doesn't handle weird-sized memory accesses, e.g. 28 bytes

TEST(MacTests, FegetenvTest) {
  fenv_t tmp;
  if (fegetenv(&tmp) != 0)
    FAIL() << "fegetenv failed";
}

->

ThreadSanitizer: ts_valgrind.cc:1031
(void instrument_mem_access(TraceInfo*, IRTemp, uintptr_t, size_t*, IRSB*, 
IRStmt*, IRExpr*, Int, Bool, Bool, Int)):
Assertion 'szB == 1 || szB == 2 || szB == 4 || szB == 8 || szB == 10 || szB == 
16' failed.

"fegetenv" does a 28-bytes access

Original issue reported on code.google.com by timurrrr on 18 May 2010 at 12:10

Replace all asserts in ThreadSanitizerTest with proper checking and exception throwing

Assertion statements make sense when we want to run a program in two modes:
debug and release. In tests we only have debug mode.

It is rather easy to get caught by not running a JVM with -ea and missing
important tricky errors (including VerifyError) because exception handlers
do just asserts. Bad style.

Anytime somebody has an empty catch clause they should have a creepy
feeling. There are definitely times when it is actually the correct thing
to do, but at least you have to think about it. In Java you can't escape
the creepy feeling.
- James Gosling

Original issue reported on code.google.com by [email protected] on 29 Apr 2010 at 2:04

ThreadSanitizer under Mac OS X hangs on some Google Chromium tests on which "aspacem" was previously reported.

To reproduce:
1. Check out and build the Chromium tests (see dev.chromium.org for the
build instruction)
2. Run the current version of ThreadSanitizer on one of the tests from the
list below.
3. Observe the hangs.

At the moment we consider this a Valgrind bug (see
https://bugs.kde.org/show_bug.cgi?id=192634 for more details), because
previously (as of May 2009 -- see the corresponding Valgrind versions)
every Valgrind tool reported the "aspacem" warnings for these tests. After
some refactoring of the address space manager done by Julian Seward in
August 2009 the "aspacem" warnings have gone, but the bug seems to still
remain within ThreadSanitizer.

Valgrind authors have decided to rework the aspacemgr completely in 3.6.0
(see https://bugs.kde.org/show_bug.cgi?id=203254). We hope this should fix
our problems as well.

Original issue reported on code.google.com by [email protected] on 14 Sep 2009 at 3:30

Probably broken stacks (thread creation; current access stack)

pin.exe -t ...\x86-windows-debug-ts_pin.dll -short_name 
--pure-happens-before=yes --ignore-in-dtor=no --announce-threads 
--debug_phase=thread -- src/build/Debug\net_unittests 
--gtest_filter="*DiskCache*"

-->

T1:  THR_START parent: T0 : [0:75631;] [0:75630; 1:1;]
T1 Thread finished
T2:  THR_START parent: T0 : [0:79879; 1:320;] [0:79878; 1:320; 2:1;]
INFO: T0 is program's main thread
INFO: T2 has been created by T0 at this point: {{{
    #0  operator delete f:\dd\vctools\crt_bld\self_x86\crt\src\dbgdel.cpp:37
    #1  std::allocator<wchar_t>::deallocate c:\program files (x86)\microsoft visual studio 9.0\vc\include\xmemory:140
    #2  std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::_Tidy c:\program files (x86)\microsoft visual studio 9.0\vc\include\xstring:2156
    #3  std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::~basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > c:\program files (x86)\microsoft visual studio 9.0\vc\include\xstring:906
    #4  FilePath::~FilePath src\build\Debug\net_unittests.exe
    #5  `anonymous namespace'::DelayedCacheCleanup src\net\disk_cache\backend_impl.cc:134
    #6  disk_cache::BackendImpl::CreateBackend src\net\disk_cache\backend_impl.cc:228
    #7  disk_cache::CreateCacheBackend src\net\disk_cache\backend_impl.cc:173
    #8  DiskCacheTest_Backend_DeleteOld_Test::TestBody src\net\disk_cache\backend_unittest.cc:1081
}}}
WARNING: Possible data race during write of size 8 at 006AEE78: {{{
   T2 (locks held: {}):
    #0  `anonymous namespace'::DeleteFiles src\net\disk_cache\cache_util_win.cc:22
    #1  LdrLoadAlternateResourceModuleEx C:\Windows\SysWOW64\ntdll.dll
    #2  RtlDetermineDosPathNameType_U C:\Windows\SysWOW64\ntdll.dll
    #3  RtlDosPathNameToRelativeNtPathName_U C:\Windows\SysWOW64\ntdll.dll
    #4  FindFirstFileExW C:\Windows\syswow64\kernel32.dll
    #5  FindFirstFileW C:\Windows\syswow64\kernel32.dll
    #6  `anonymous namespace'::DeleteFiles src\net\disk_cache\cache_util_win.cc:22
    #7  disk_cache::DeleteCache src\net\disk_cache\cache_util_win.cc:53
    #8  `anonymous namespace'::CleanupTask::Run src\net\disk_cache\backend_impl.cc:93
    #9  `anonymous namespace'::WorkItemCallback src\base\worker_pool_win.cc:16
    #10 RtlMultiByteToUnicodeSize C:\Windows\SysWOW64\ntdll.dll
    #11 RtlReleaseSRWLockShared C:\Windows\SysWOW64\ntdll.dll
  Concurrent write(s) happened at (OR AFTER) these points:
   T0 (locks held: {}):
    #0  file_util::CreateDirectoryW src\base\file_util_win.cc:537
    #1  disk_cache::BackendImpl::InitBackingStore src\net\disk_cache\backend_impl.cc:1042
    #2  disk_cache::BackendImpl::Init src\net\disk_cache\backend_impl.cc:251
    #3  disk_cache::BackendImpl::CreateBackend src\net\disk_cache\backend_impl.cc:237
    #4  disk_cache::CreateCacheBackend src\net\disk_cache\backend_impl.cc:173
    #5  DiskCacheTest_Backend_DeleteOld_Test::TestBody src\net\disk_cache\backend_unittest.cc:1081
}}}

Original issue reported on code.google.com by timurrrr on 26 Feb 2010 at 9:39

Can't run TSan on Windows binaries build in Release mode

I remember there were some issues with running TSan on Release test builds.

Can you please remind us what they were?
I think we can speed TSan/Win for Chromium a lot if we work around these issues 
(if possible).

Original issue reported on code.google.com by timurrrr on 27 Oct 2010 at 8:50

Code review request

Purpose of code changes on this branch:
A unit test for trylocks.

When reviewing my code changes, please focus on:


After the review, I'll merge this branch into:
/trunk/unittest

Original issue reported on code.google.com by [email protected] on 1 Jul 2009 at 1:12

Setup a buildbot

Setup a buildbot for Thread Sanitizer.

Original issue reported on code.google.com by [email protected] on 12 Jan 2010 at 2:56

jtsan: strange race report

cd jtsan && make && ./jtsan.sh ThreadSanitizerTest testNegative_NoReportOnLocks 
 &&  ../tsan/bin/amd64-linux-debug-ts_offline --show-pc < 
jtsan.events

==22725== INFO: T8 has been created by T0. Use --announce-threads to see the 
creation stack.
==22725== INFO: T7 has been created by T0. Use --announce-threads to see the 
creation stack.
==22725== WARNING: Possible data race during read of size 1 at 0x2140609276: {{{
==22725==    T8 (locks held: {}):
==22725==     #0  0x132: ThreadSanitizerTest$20.thread2 
ThreadSanitizerTest.java:613
==22725==     #1  0x154: ThreadSanitizerTest$ThreadRunner.foo2 
ThreadSanitizerTest.java:124
==22725==     #2  0x180: ThreadSanitizerTest$ThreadRunner$3.<init> 
ThreadSanitizerTest.java:139
==22725==     #3  0x168: ThreadSanitizerTest$ThreadRunner.<init> 
ThreadSanitizerTest.java:146
==22725==   Concurrent write(s) happened at (OR AFTER) these points:
==22725==    T7 (locks held: {}):
==22725==     #0  0x128: ThreadSanitizerTest$20.thread1 
ThreadSanitizerTest.java:610
==22725==     #1  0x152: ThreadSanitizerTest$ThreadRunner.foo1 
ThreadSanitizerTest.java:123
==22725==     #2  0x176: ThreadSanitizerTest$ThreadRunner$1MyThread.<init> 
ThreadSanitizerTest.java:132
==22725==     #3  0x168: ThreadSanitizerTest$ThreadRunner.<init> 
ThreadSanitizerTest.java:146
==22725== }}}

This shoudn't happen, there is no race here. 

Looking at events: 
WRITE 0 154 227180285 1
WRITE 7 125 227180285 1
WRITE 8 127 227180285 1

this looks very strange. One of these events (from thread 8) shouldn't appear 
at all.

Original issue reported on code.google.com by [email protected] on 1 Feb 2010 at 11:41

Java: Support ReentrantReadWriteLock

Egor, I need your help with support for ReentrantReadWriteLock.


1. When intercepting methods from ReentrantReadWriteLock$WriteLock I need to 
have the enclosing object (ReentrantReadWriteLock). Is there a way to get it? 
Or I have to intercept ReentrantReadWriteLock$WriteLock's CTOR to get the 
enclosing object? How do I intercept the CTOR? 

2. When interceping tryLock() (after the call) I need to get the return 
value. How?

Original issue reported on code.google.com by [email protected] on 1 Mar 2010 at 8:20

Java: jtsan fails to detect THR_START event on a simple test

% cat RaceExample.java
public class RaceExample {
  public static int racey_var;

  static class RaceThread extends Thread {
    public void run() {
      RaceExample.racey_var++;
    }
  }

  public static void main(String args[]) {
    (new RaceThread()).start();
    (new RaceThread()).start();
    System.out.printf("racey_var=%d\n", racey_var);
  }
}
% javac RaceExample.java
% java RaceExample
racey_var=1
% ./jtsan.sh RaceExample
Java Agent: appending threading events to file: jtsan.events
racey_var=0
% grep THR_ jtsan.events
THR_START 0 0 0 0
THR_FIRST_INSN 0 0 0 0
%

Original issue reported on code.google.com by [email protected] on 1 Mar 2010 at 3:46

Code review request

Purpose of code changes on this branch:
A unit test for trylock interception in Tsan.

When reviewing my code changes, please focus on:


After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 1 Jul 2009 at 11:16

exclude list in jtsan/Makefile tests lacks verbosity

It is hard to follow what reasons has lead to exclusion of particular tests. We 
need to comment each exclusion with a link to corresponding bug.

Original issue reported on code.google.com by [email protected] on 5 Aug 2010 at 7:03

Need to fix stacktrace output inconsistencies on Valgrind vs. PIN

output_tests1, V.:  void Thread1() {} --> #0  Thread1()
output_tests1, PIN: void Thread1() {} --> #0  Thread1
fun_hist_test, V.:  extern "C" Thread1() {} --> #0 Thread1
fun_hist_test, PIN: extern "C" Thread1() {} --> #0 Thread1

Original issue reported on code.google.com by timurrrr on 20 May 2010 at 2:43

ASSERT SegmentSet::Validate (thread_sanitizer.cc:2380) !Segment::HappensBefore(GetSID(i), GetSID(j))

This happens on TSan/Pin on Windows when running Chromium net_unittests.

BAD at line 2215: 1 0 T6/S424878 T12/S427684
   [0:948048; 1:279; 2:387; 3:306; 4:17; 5:1; 6:12; 7:33; 9:97;]
   [0:950633; 1:279; 2:387; 3:306; 4:19; 5:1; 6:12; 7:33; 9:216; 12:35;]
T0
    #0   
    #1  NtWaitForSingleObject C:\Windows\SysWOW64\ntdll.dll
    #2  WaitForSingleObjectEx C:\Windows\syswow64\kernel32.dll
    #3  WaitForSingleObjectEx C:\Windows\syswow64\kernel32.dll
    #4  base::WaitableEvent::TimedWait base\waitable_event_win.cc:63
    #5  net::TCPPinger::Worker::TimedWaitForResult net\socket\tcp_pinger.h:108
    #6  net::TCPPinger::Ping net\socket\tcp_pinger.h:57
    #7  net::TestServerLauncher::WaitToStart net\socket\ssl_test_util.cc:321
    #8  net::TestServerLauncher::Start net\socket\ssl_test_util.cc:298
    #9  SSLClientSocketTest::StartOKServer net\socket\ssl_client_socket_unittest.cc:35
    #10 SSLClientSocketTest_Read_FullDuplex_Test::TestBody net\socket\ssl_client_socket_unittest.cc:261
    #11 testing::Test::Run testing\gtest\src\gtest.cc:2060
T1
    #0   
    #1  ZwTerminateThread C:\Windows\SysWOW64\ntdll.dll
    #2  LdrShutdownThread C:\Windows\SysWOW64\ntdll.dll
    #3  TpAllocPool C:\Windows\SysWOW64\ntdll.dll
    #4  TpCallbackMayRunLong C:\Windows\SysWOW64\ntdll.dll
    #5  BaseThreadInitThunk C:\Windows\syswow64\kernel32.dll
T2
    #0   
    #1  ZwTerminateThread C:\Windows\SysWOW64\ntdll.dll
    #2  LdrShutdownThread C:\Windows\SysWOW64\ntdll.dll
    #3  TpAllocPool C:\Windows\SysWOW64\ntdll.dll
    #4  TpCallbackMayRunLong C:\Windows\SysWOW64\ntdll.dll
    #5  BaseThreadInitThunk C:\Windows\syswow64\kernel32.dll
T3
    #0   
    #1  ZwTerminateThread C:\Windows\SysWOW64\ntdll.dll
    #2  LdrShutdownThread C:\Windows\SysWOW64\ntdll.dll
    #3  TpAllocPool C:\Windows\SysWOW64\ntdll.dll
    #4  TpCallbackMayRunLong C:\Windows\SysWOW64\ntdll.dll
    #5  BaseThreadInitThunk C:\Windows\syswow64\kernel32.dll
T4
    #0   
    #1  ZwWaitForWorkViaWorkerFactory C:\Windows\SysWOW64\ntdll.dll
    #2  RtlMultiByteToUnicodeSize C:\Windows\SysWOW64\ntdll.dll
    #3  TpCallbackMayRunLong C:\Windows\SysWOW64\ntdll.dll
    #4  BaseThreadInitThunk C:\Windows\syswow64\kernel32.dll
T5
    #0   
    #1  ZwTerminateThread C:\Windows\SysWOW64\ntdll.dll
    #2  LdrShutdownThread C:\Windows\SysWOW64\ntdll.dll
    #3  TpSimpleTryPost C:\Windows\SysWOW64\ntdll.dll
    #4  TpSimpleTryPost C:\Windows\SysWOW64\ntdll.dll
    #5  BaseThreadInitThunk C:\Windows\syswow64\kernel32.dll
T7
    #0   
    #1  ZwWaitForWorkViaWorkerFactory C:\Windows\SysWOW64\ntdll.dll
    #2  RtlMultiByteToUnicodeSize C:\Windows\SysWOW64\ntdll.dll
    #3  TpCallbackMayRunLong C:\Windows\SysWOW64\ntdll.dll
    #4  BaseThreadInitThunk C:\Windows\syswow64\kernel32.dll
T8
    #0   
    #1  ZwTerminateThread C:\Windows\SysWOW64\ntdll.dll
    #2  LdrShutdownThread C:\Windows\SysWOW64\ntdll.dll
    #3  TpSimpleTryPost C:\Windows\SysWOW64\ntdll.dll
    #4  TpSimpleTryPost C:\Windows\SysWOW64\ntdll.dll
    #5  BaseThreadInitThunk C:\Windows\syswow64\kernel32.dll
T10
    #0   
    #1  ZwTerminateThread C:\Windows\SysWOW64\ntdll.dll
    #2  LdrShutdownThread C:\Windows\SysWOW64\ntdll.dll
    #3  TpSimpleTryPost C:\Windows\SysWOW64\ntdll.dll
    #4  TpSimpleTryPost C:\Windows\SysWOW64\ntdll.dll
    #5  BaseThreadInitThunk C:\Windows\syswow64\kernel32.dll
T11
    #0   
    #1  NtWaitForMultipleObjects C:\Windows\SysWOW64\ntdll.dll
    #2  TpSimpleTryPost C:\Windows\SysWOW64\ntdll.dll
    #3  TpSimpleTryPost C:\Windows\SysWOW64\ntdll.dll
    #4  BaseThreadInitThunk C:\Windows\syswow64\kernel32.dll
T12
    #0  RtlLeaveCriticalSection C:\Windows\SysWOW64\ntdll.dll
    #1  unnamedImageEntryPoint C:\Windows\system32\mswsock.dll
    #2  unnamedImageEntryPoint C:\Windows\system32\mswsock.dll
    #3  unnamedImageEntryPoint C:\Windows\system32\mswsock.dll
    #4  connect C:\Windows\syswow64\WS2_32.dll
    #5  net::TCPClientSocketWin::DoConnect net\socket\tcp_client_socket_win.cc:342
    #6  net::TCPClientSocketWin::Connect net\socket\tcp_client_socket_win.cc:305
    #7  net::TCPPinger::Worker::DoConnect net\socket\tcp_pinger.h:89
    #8  DispatchToMethod<net::TCPPinger::Worker,void (__thiscall net::TCPPinger::Worker::*)(void)> base\tuple.h:412
    #9  RunnableMethod<net::TCPPinger::Worker,void (__thiscall net::TCPPinger::Worker::*)(void),Tuple0>::Run base\task.h:289
    #10 MessageLoop::RunTask base\message_loop.cc:320
    #11 MessageLoop::DeferOrRunPendingTask base\message_loop.cc:328

Original issue reported on code.google.com by timurrrr on 16 Feb 2010 at 10:51

Testing the issue tracker

[this issue will be removed soon]
    #4  void
STLDeleteContainerPointers<__gnu_cxx::__normal_iterator<net::HostResolverImpl::R
equest**,
std::vector<net::HostResolverImpl::Request*,
std::allocator<net::HostResolverImpl::Request*> > >
>(__gnu_cxx::__normal_iterator<net::HostResolverImpl::Request**,
std::vector<net::HostResolverImpl::Request*,
std::allocator<net::HostResolverImpl::Request*> > >,
__gnu_cxx::__normal_iterator<net::HostResolverImpl::Request**,
std::vector<net::HostResolverImpl::Request*,
std::allocator<net::HostResolverImpl::Request*> > >) base/stl_util-inl.h:65

Original issue reported on code.google.com by timurrrr on 22 Sep 2009 at 1:59

java sanitizer test for racey access to standard non-synchronized collections (example: HashSet)

How it is different from existing tests: HashSet is a system class. This
test should check how an instrumentation-based thread checker instruments
system classes or knows about semantics of collections.

Original issue reported on code.google.com by [email protected] on 6 Aug 2009 at 10:30

Signal handlers crash under ThreadSanitizer/Debug build on Mac

http://build.chromium.org/buildbot/tsan/builders/buildbot-mac/builds/4297
[ RUN      ] Signals.PositiveTests_RaceInSignal
==26115== ThreadSanitizer, a data race detector
==26115== Copyright (C) 2008-2010, and GNU GPL'd, by Google Inc.
==26115== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==26115== Command: unittest/bin/racecheck_unittest-darwin-x86-O1
==26115== Parent PID: 26101
==26115== 
==26115== 
==26115== used_suppression: 2 dyld tries to unlock an invalid mutex when 
adding/removing image.
==26115== used_suppression: 1 fun:*test127*
==26115== used_suppression: 1 fun:*test136*
==26115== ThreadSanitizer summary: reported 0 warning(s) (0 race(s))

ThreadSanitizer: ts_valgrind.cc:818 (void SignalIn(ThreadId, Int, Bool)): 
Assertion 'g_valgrind_threads[vg_tid].in_signal_handler == 1' failed.
==26101==    at 0x38050D45: ???
==26101==    by 0x38050F08: ???
==26101==    by 0x3803D5C2: ???
==26101==    by 0x38081C45: ???
==26101==    by 0x3808272A: ???
==26101==    by 0x3809D8A0: ???
==26101==    by 0x3809E7E0: ???
==26101==    by 0x38097588: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==26101==    at 0x4D20E: Signals::child_handler(int) (in 
unittest/bin/racecheck_unittest-darwin-x86-O1)
==26101==    by 0x4D207: 
Signals::Signals_PositiveTests_RaceInSignal_Test::TestBody() (in 
unittest/bin/racecheck_unittest-darwin-x86-O1)
==26101==    by 0x384AF: testing::Test::Run() (in 
unittest/bin/racecheck_unittest-darwin-x86-O1)
==26101==    by 0x3F4E2: testing::internal::TestInfoImpl::Run() (in 
unittest/bin/racecheck_unittest-darwin-x86-O1)
==26101==    by 0x3F625: testing::TestCase::Run() (in 
unittest/bin/racecheck_unittest-darwin-x86-O1)
==26101==    by 0x3F933: testing::internal::UnitTestImpl::RunAllTests() (in 
unittest/bin/racecheck_unittest-darwin-x86-O1)
==26101==    by 0x3FA91: testing::UnitTest::Run() (in 
unittest/bin/racecheck_unittest-darwin-x86-O1)
==26101==    by 0x2945A: main (in unittest/bin/racecheck_unittest-darwin-x86-O1)

Original issue reported on code.google.com by timurrrr on 6 Sep 2010 at 9:20

TSan doesn't understand VS incremental link generated binaries

As a result, ignore files are not working.
This was caught on our bots for rev 1874

Original issue reported on code.google.com by timurrrr on 22 Mar 2010 at 11:32

jtsan: Multiple exceptions when running DaCapo benchmarks

1. Download dacapo-9.12-bach.jar from http://dacapobench.org/
2. Run jtsan.sh -jar dacapo-9.12-bach.jar eclipse 

java.lang.NullPointerException
        at org.objectweb.asm.commons.AnalyzerAdapter.pop(Unknown Source)
        at org.objectweb.asm.commons.AnalyzerAdapter.pop(Unknown Source)
        at org.objectweb.asm.commons.AnalyzerAdapter.visitMethodInsn(Unknown Source)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)
        at org.jtsan.Agent.transform(Unknown Source)
        at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
        at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:385)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:637)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336)
        at Harness.main(Unknown Source)
java.lang.NullPointerException
        at org.jtsan.MethodTransformer.visitObjectFieldAccess(Unknown Source)
        at org.jtsan.MethodTransformer.visitFieldInsn(Unknown Source)
        at org.objectweb.asm.commons.AnalyzerAdapter.visitFieldInsn(Unknown Source)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)
        at org.jtsan.Agent.transform(Unknown Source)
        at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
        at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:385)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:637)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336)
        at org.dacapo.harness.TestHarness.main(TestHarness.java:106)
        at Harness.main(Unknown Source)

Original issue reported on code.google.com by [email protected] on 12 Mar 2010 at 7:59

TSan/PIN crashes on an assertion TLEBUnlocked if shut down with Ctrl+C

This is not really a problem, but may confuse some analyzer scripts in some 
cases

Original issue reported on code.google.com by timurrrr on 27 Feb 2010 at 9:58

Fix and enable SimpleDeathTest on windows (pin)

On windows the test behaves strangely: looks like after the death test is 
done PIN detaches from the parent process.

Original issue reported on code.google.com by [email protected] on 12 Feb 2010 at 10:08

We should handle signal handlers as separate threads

Example code with a data race (see the printf) which can't be found by 
ThreadSanitizer as of r2427:
===test.c===
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>

pid_t child_pid = 0;
int ret = 0;

void child_handler(int signum) {
  if (signum == SIGCHLD && child_pid == 0) {
    printf("Whoops, PID shouldn't be 0!\n");
    ret = 1;
  }
}

int main(void) {
  signal(SIGCHLD, child_handler);
  child_pid = fork();
  if (child_pid == 0) {
    // in child 
    exit(0);
  }
  wait(NULL);
  return ret;
}
===========
$ gcc test.c
$ while ./a.out ; do echo "PASS"; done
PASS
...
PASS
Whoops, PID shouldn't be 0!

This test case was suggested by Denis Lunev

Original issue reported on code.google.com by timurrrr on 1 Sep 2010 at 1:07

enable DISABLED_StartAndJoinManyThreads

Thread creation is expensive. 
If we create, say 5000 threads at once, it takes forever.
Need to fix.

Original issue reported on code.google.com by [email protected] on 11 Feb 2010 at 1:38

Jtsan reports false positives on static synchronized methods

Jtsan doesn't create LOCK / UNLOCK events on static synchronized methods.

Reproduced on test staticSync
http://code.google.com/p/java-thread-sanitizer/source/browse/trunk/tests/CustomT
ests.java?r=125#129

and staticSync3
http://code.google.com/p/java-thread-sanitizer/source/browse/trunk/tests/CustomT
ests.java?r=125#102

Original issue reported on code.google.com by [email protected] on 11 Oct 2010 at 12:52

java: jtsan crashes on CyclicBarrier.await

Reproduce: 
./jtsan.sh  ThreadSanitizerTest testNegative_CyclicBarrier


Stack dump: 
======================= testNegative_CyclicBarrier =======================
Correct code: CyclicBarrier
Exception occured during transformation. Transformed bytes are discarded.
java.lang.RuntimeException: java.lang.ClassNotFoundException: 
ThreadSanitizerTest$30
        at org.objectweb.asm.ClassWriter.getCommonSuperClass(Unknown Source)
        at org.objectweb.asm.ClassWriter.a(Unknown Source)
        at org.objectweb.asm.Frame.a(Unknown Source)
        at org.objectweb.asm.Frame.a(Unknown Source)
        at org.objectweb.asm.MethodWriter.visitMaxs(Unknown Source)
        at org.objectweb.asm.commons.LocalVariablesSorter.visitMaxs(Unknown Source)
        at org.jtsan.MethodTransformer.visitMaxs(Unknown Source)
        at org.objectweb.asm.commons.AnalyzerAdapter.visitMaxs(Unknown Source)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)
        at org.jtsan.Agent.transform(Unknown Source)
        at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
        at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:385)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:637)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336)
        at ThreadSanitizerTest.testNegative_CyclicBarrier(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at ThreadSanitizerTest.main(Unknown Source)

Original issue reported on code.google.com by [email protected] on 1 Mar 2010 at 2:13

False reports on file system calls: CreateFile/GetFileAttributes vs. FindFirstFile

See NegativeTests.CreateFileVsFindFirstFileTest for the details (disabled at 
the moment).

A similar situation is happening in Chromium net_unittests

Original issue reported on code.google.com by timurrrr on 28 Apr 2010 at 2:57

Java: support arrays, float, double, long

Need to support all basic types in Java. 

Tests: 
testNegative_WW_ArrayAccessNoLocks
testPositive_WW_ArrayAccessNoLocks
testPositive_WW_NoLocksFloat
testPositive_WW_NoLocksDouble
testPositive_WW_NoLocksLong

Original issue reported on code.google.com by [email protected] on 1 Mar 2010 at 9:10

jtsan - Final buffer flush

We lose lost events in BinaryEventWriter

Original issue reported on code.google.com by [email protected] on 5 Aug 2010 at 12:53

Reports on std::string internal rep

The implementation of basic_string<> contains atomic reference counting without 
annotations.
Currently, this gives TSan reports with --free-is-write=yes

See NegativeTests.StdStringDtor for a reproducer.

Proposal to modify the std::string sent to gcc team:
http://gcc.gnu.org/ml/libstdc++/2010-07/msg00029.html

Original issue reported on code.google.com by timurrrr on 21 Jul 2010 at 12:44

Made racecheck_unittest runnable under Tsan on Mac OS

Purpose of code changes on this branch:


When reviewing my code changes, please focus on:


After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 1 Jul 2009 at 8:03

StringMatch("zzz", "zzz") returns false

StringMatch("*zzz*", "zzz") returns false
please also add more tests

Original issue reported on code.google.com by [email protected] on 27 Jan 2010 at 11:39

Add support for Mac OS X 10.6

Alexander,
Can you please update this issue with the current status of TSan on 10.6 ?

Original issue reported on code.google.com by timurrrr on 18 Aug 2010 at 12:26

Code review request

Purpose of code changes on this branch:
Port racecheck_unittest on Mac OS X

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by timurrrr on 13 May 2009 at 10:48

Made racecheck_unittest runnable under Tsan on Mac OS

Purpose of code changes on this branch:


When reviewing my code changes, please focus on:


After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 1 Jul 2009 at 7:55

Need to fix stacktrace output inconsistencies on Valgrind vs. PIN

output_tests1, V.:  void Thread1() {} --> #0  Thread1()
output_tests1, PIN: void Thread1() {} --> #0  Thread1
fun_hist_test, V.:  extern "C" Thread1() {} --> #0 Thread1
fun_hist_test, PIN: extern "C" Thread1() {} --> #0 Thread1

Original issue reported on code.google.com by timurrrr on 20 May 2010 at 2:43

Merged into: #37

Code review request

Purpose of code changes on this branch:
Two regression tests for RWLock trylocks.

When reviewing my code changes, please focus on:


After the review, I'll merge this branch into:
/trunk/unittest

Original issue reported on code.google.com by [email protected] on 1 Jul 2009 at 10:27

Support TLS on tsan/windows

Currently, NegativeTests.PerThreadTest fails on windows because when thread 
local storage is reused we don't clean it up.

Original issue reported on code.google.com by [email protected] on 17 Feb 2010 at 10:54

Assertion 'wait_cv_and_mu_set_ == false' failed

(initially reports by jyasskin on python)

tsan fails in assertion on test158:

ThreadSanitizer: thread_sanitizer.cc:3803 (void 
Thread::HandleWaitBefore(uintptr_t, uintptr_t)): Assertion 'wait_cv_and_mu_set_ 
== false' failed.
==22586==    at 0x38085CF4: report_and_quit (m_libcassert.c:145)
==22586==    by 0x38085F77: vgPlain_assert_fail (m_libcassert.c:217)
==22586==    by 0x3805F209: Detector::HandleWaitBefore() 
(thread_sanitizer.cc:3803)
==22586==    by 0x3801B27C: ThreadSanitizerHandleOneEvent(Event*) 
(thread_sanitizer.cc:4996)
==22586==    by 0x380235F1: Put(EventType, int, unsigned long, unsigned long, 
unsigned long) (ts_valgrind.cc:298)
==22586==    by 0x380239CA: ts_handle_client_request(unsigned int, unsigned 
long*, unsigned long*) (ts_valgrind.cc:575)
==22586==    by 0x380BDA8E: vgPlain_scheduler (scheduler.c:1498)
==22586==    by 0x380E6D29: run_a_thread_NORETURN (syswrap-linux.c:91)
==22586==    by 0x380E6F2A: vgModuleLocal_start_thread_NORETURN 
(syswrap-linux.c:214)
==22586==    by 0x380E993D: ??? (in 
/home/kcc/tsan_inst/lib/valgrind/tsan-amd64-linux)
==22586==    by 0xDEADBEEFDEADBEEE: ???
==22586==    by 0xDEADBEEFDEADBEEE: ???
==22586==    by 0xDEADBEEFDEADBEEE: ???

What happens: 

sem_wait_WRK (or similar) generates event 'WAIT_BEFORE'
signall arrives 
signal handler make some other sync call which generates event 'WAIT_BEFORE'

Current tsan's logic assumes that WAIT_BEFORE must be followed by WAIT_AFTER 
and the assertion fires.

Original issue reported on code.google.com by [email protected] on 11 Jan 2010 at 9:50

Handle RegisterWaitForSingleObject/UnregisterWaitEx correctly

See NegativeTests.RegisterWaitForSingleObjectTest (disable atm)
in unittest/windows_tests.cc

--------------------------------------------------------
FYI, the list of functions called by the thread from the 
RegisterWaitForSingleObject pool is:
BaseThreadInitThunk
GetModuleHandleW
NtContinue
NtTestAlert
NtWaitForSingleObject
NtWorkerFactoryWorkerReady
RtlAcquireSRWLockShared
RtlCreateUserProcess
RtlDllShutdownInProgress
RtlGetCurrentPeb
RtlImageNtHeader
RtlImageNtHeaderEx
RtlInitializeExceptionChain
RtlIsActivationContextActive
RtlIsCriticalSectionLockedByThread
RtlIsCurrentThreadAttachExempt
RtlNtStatusToDosError
RtlNtStatusToDosErrorNoTeb
RtlProcessFlsData
RtlQueryElevationFlags
RtlRegisterThreadWithCsrss
RtlSleepConditionVariableSRW
RtlTimeToTimeFields
RtlpInterlockedPopEntrySeqSListEnd
SetLastError
TpPostWork
TpReleaseTimer
ZwAllocateVirtualMemory
_lock
_unlock

Original issue reported on code.google.com by timurrrr on 24 Feb 2010 at 3:07

Code review request

Purpose of code changes on this branch:
Optimized SegmentSet recycling algo: O(1) instead of O(#SSID), more
consistent execution speed

Original issue reported on code.google.com by timurrrr on 19 Feb 2009 at 2:22

ThreadSanitizer dies with misaligned stack errors on Mac OS

To reproduce, sync third_party/valgrind to r75, build TSan and run:

$ tsan_inst/bin/valgrind  --tool=tsan ls
==82415== ThreadSanitizer, a data race detector
==82415== Copyright (C) 2008-2010, and GNU GPL'd, by Google Inc.
==82415== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
==82415== Command: ls
==82415== 
==82415== ThreadSanitizerValgrind r2526: hybrid=no
==82415== INFO: Allocating 192Mb (24 * 8M) for Segments.
==82415== INFO: Will allocate up to 320Mb for 'previous' stack traces.
--82415-- 
/Users/glider/src/data-race-test/tsan/bin/vgpreload_tsan-x86-darwin.so:
--82415-- dSYM directory is missing; consider using --dsymutil=yes
==82415== 
==82415== Process terminating with default action of signal 11 (SIGSEGV)
==82415==  General Protection Fault
==82415==    at 0x8FE18C02: misaligned_stack_error (in /usr/lib/dyld)
==82415==    by 0xA16B2EB: _malloc_initialize (in /usr/lib/libSystem.B.dylib)
==82415==    by 0xA091803: calloc (in /usr/lib/libSystem.B.dylib)
==82415==    by 0xA01D88B: calloc (in 
/Users/glider/src/data-race-test/tsan/bin/vgpreload_tsan-x86-darwin.so)
==82415==    by 0xA091799: dwarf2_unwind_dyld_add_image_hook (in 
/usr/lib/libSystem.B.dylib)
==82415==    by 0x8FE03D61: dyld::registerAddCallback(void (*)(mach_header 
const*, long)) (in /usr/lib/dyld)
==82415==    by 0xA090B3A: _dyld_register_func_for_add_image (in 
/usr/lib/libSystem.B.dylib)
==82415==    by 0xA089CB5: __keymgr_initializer (in /usr/lib/libSystem.B.dylib)
==82415==    by 0xA0890C0: libSystem_initializer (in /usr/lib/libSystem.B.dylib)
==82415==    by 0x8FE12F35: 
ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in 
/usr/lib/dyld)
==82415==    by 0x8FE0E7E2: 
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned 
int) (in /usr/lib/dyld)
==82415==    by 0x8FE0E774: 
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned 
int) (in /usr/lib/dyld)
==82415== 
==82415== ThreadSanitizer summary: reported 0 warning(s) (0 race(s))
Segmentation fault

Original issue reported on code.google.com by [email protected] on 27 Oct 2010 at 8:03

32 bit offline race detector fails to work with 64 bit unique object identifiers

if in jtsan.events WRITE and Co. appears with 64 bit object identifiers,
offline detector fails like this:

$ ../tsan/bin/x86-linux-debug-ts_offline < jtsan.events > jtsan.out
x86-linux-debug-ts_offline: ts_heap_info.h:84: bool
HeapMap<HeapInfo>::IsHeapMem(uintptr_t, HeapInfo*) [with HeapInfo =
HeapInfo]: Assertion `IsValidPtr(a)' failed.

jtsan.events is attached

Original issue reported on code.google.com by [email protected] on 11 Feb 2010 at 9:18

Attachments:

jtsan.events

False negative in pure happens-before mode: write on ReaderLock

What steps will reproduce the problem?
1. ThreadSanitizerTest.java testPositive_WritingUnderReaderLock

What is the expected output? What do you see instead?
Expected race but sometimes in pure happens-before mode we report no races.

Original issue reported on code.google.com by [email protected] on 4 Aug 2010 at 4:35

trietptm / data-race-test Goto Github PK

data-race-test's Introduction

Hi there 👋

GitHub Stats

data-race-test's People

Contributors

Stargazers

Watchers

data-race-test's Issues

Recommend Projects

Recommend Topics

Recommend Org