theRockLiu / thread-sanitizer

Automatically exported from code.google.com/p/thread-sanitizer
0 stars 0 forks source link

deadlock detector: Does not detect simple AB BA deadlock with 2 threads #85

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Compile attached program with -fsanitize=thread with either gcc or clang:

   $ gcc -fsanitize=thread -fPIC -pie -g -Wall tsan-deadlock.c

2. Run it.

   $ ./a.out

What is the expected output? What do you see instead?

Expected output is: TSAN reports there is locking cycle.
I see: nothing - the program just deadlocks and hangs forever.

What version of the product are you using? On what operating system?

$ uname -a
Linux teco 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2 (2014-11-06) x86_64 GNU/Linux

I've tested with both relatively current clang-3.6 and gcc-5:

$ clang-3.6 --version
Debian clang version 3.6.0-svn218612-1 (trunk) (based on LLVM 3.6.0)
Target: x86_64-pc-linux-gnu
Thread model: posix

$ gcc --version
gcc (Debian 20141118-1) 5.0.0 20141118 (experimental) [trunk revision 217719]

and I've also tested with manually built libtsan.so.0 from today's compiler-rt 
git head (375a4d07 dvyukov, Dec 5 2014) used via LD_LIBRARY_PATH.

Please provide any additional information below.

The test program reliably deadlocks taking two locks L1 & L2 in
different order on different threads:

      T0      T1

      L1      L2
      L2      L1

i.e. it's a classic deadlock.

"Reliable" because of added sleeps, so that P(deadlock) is close to 100%.

With deadlock detector TSAN should catch this locking cycle with and without
sleeps. Currently no error is reported.

Thanks beforehand,
Kirill

Original issue reported on code.google.com by kirill.s...@gmail.com on 5 Dec 2014 at 2:43

Attachments:

GoogleCodeExporter commented 9 years ago
Yea, I know.... 
tsan currently will find a *potential* lock inversion but will fail to report 
if the deadlock has actually happened.

Agree, this needs to be fixed, just didn't have time for this lately. 
This is relatively low priority because if a deadlock already happened gdb is 
often enough to diagnose it, while potential deadlocks are harder to catch. 

Original comment by konstant...@gmail.com on 5 Dec 2014 at 11:41