runt18 / data-race-test Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/data-race-test
Automatically exported from code.google.com/p/data-race-test
This project aims to create a test suite for helgrind (a data race detection tool, part of valgrind, http://www.valgrind.org) and potentially any other data race detector. Hopefully, everything really useful from this project will eventually be merged into the 'official' helgrind. For details, see http://code.google.com/p/data-race-test
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
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
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
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
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
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
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
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
[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
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
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
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
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
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
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
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
% 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
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
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
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
(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
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
We lose lost events in BinaryEventWriter
Original issue reported on code.google.com by [email protected]
on 5 Aug 2010 at 12:53
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
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
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
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
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
Setup a buildbot for Thread Sanitizer.
Original issue reported on code.google.com by [email protected]
on 12 Jan 2010 at 2:56
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
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
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
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
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
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
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
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
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
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
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
"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
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
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
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:
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
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
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
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
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.