[compiler-rt] r212532 - tsan: fix a potential hang
Alexey Samsonov
vonosmas at gmail.com
Tue Jul 8 13:29:04 PDT 2014
I've reverted this (and r212531) in r212562. "check-tsan" command hanged in
the following test:
#0 0x00007fcc4406b148 in pthread_join (threadid=140514703693568,
thread_return=0x0) at pthread_join.c:89
#1 0x00007fcc444eec1e in __interceptor_pthread_join (th=0x7fcc20ffd700,
ret=0x0) at llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896
#2 0x00007fcc445472e6 in LockTest::RunThreads (this=0x7fff7b7708b0,
f1=(void (LockTest::*)(LockTest * const)) 0x7fcc44548750
<LockTest::CreateAndDestroyLocksLoop()>,
f2=(void (LockTest::*)(LockTest * const)) 0x7fcc44548750
<LockTest::CreateAndDestroyLocksLoop()>, f3=(void (LockTest::*)(LockTest *
const)) 0x7fcc44548750 <LockTest::CreateAndDestroyLocksLoop()>,
f4=(void (LockTest::*)(LockTest * const)) 0x7fcc44548750
<LockTest::CreateAndDestroyLocksLoop()>) at
llvm/projects/compiler-rt/test/tsan/deadlock_detector_stress_test.cc:563
#3 0x00007fcc4454661c in LockTest::Test14 (this=0x7fff7b7708b0) at
llvm/projects/compiler-rt/test/tsan/deadlock_detector_stress_test.cc:414
with the following stack trace:
#0 __tsan::MetaMap::GetAndLock (this=0x7fcc4477ec88
<__tsan::ctx_placeholder+8>, thr=thr at entry=0x7fcc20f94840,
pc=pc at entry=140515296005860,
addr=addr at entry=140514703260608, write_lock=write_lock at entry=true,
create=create at entry=true) at
llvm/projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:155
#1 0x00007fcc4452ff8f in __tsan::MetaMap::GetOrCreateAndLock
(this=<optimized out>, thr=thr at entry=0x7fcc20f94840,
pc=pc at entry=140515296005860,
addr=addr at entry=140514703260608, write_lock=write_lock at entry=true)
at llvm/projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:122
#2 0x00007fcc44527217 in __tsan::MutexCreate (thr=0x7fcc20f94840,
pc=pc at entry=140515296005860, addr=addr at entry=140514703260608,
rw=rw at entry=false,
recursive=<optimized out>, linker_init=linker_init at entry=false)
at llvm/projects/compiler-rt/lib/tsan/rtl/tsan_rtl_mutex.cc:79
#3 0x00007fcc444dcfc4 in __interceptor_pthread_mutex_init
(m=0x7fcc20f93bc0, a=0x0) at
llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1041
#4 0x00007fcc44547a03 in PthreadMutex::PthreadMutex (this=0x7fcc20f93bc0,
recursive=false) at
llvm/projects/compiler-rt/test/tsan/deadlock_detector_stress_test.cc:35
#5 0x00007fcc44548823 in LockTest::CreateAndDestroyLocksLoop
(this=0x7fff7b7708b0) at
llvm/projects/compiler-rt/test/tsan/deadlock_detector_stress_test.cc:529
#6 0x00007fcc44547d0c in LockTest::Thread (param=0x7fff7b770470) at
llvm/projects/compiler-rt/test/tsan/deadlock_detector_stress_test.cc:551
On Tue, Jul 8, 2014 at 6:37 AM, Dmitry Vyukov <dvyukov at google.com> wrote:
> Author: dvyukov
> Date: Tue Jul 8 08:36:59 2014
> New Revision: 212532
>
> URL: http://llvm.org/viewvc/llvm-project?rev=212532&view=rev
> Log:
> tsan: fix a potential hang
>
> idx0 is not updated in the branch,
> so if we take that branch idx0 will stay updated forever
>
>
>
> Modified:
> compiler-rt/trunk/lib/tsan/rtl/tsan_sync.cc
>
> Modified: compiler-rt/trunk/lib/tsan/rtl/tsan_sync.cc
> URL:
> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_sync.cc?rev=212532&r1=212531&r2=212532&view=diff
>
> ==============================================================================
> --- compiler-rt/trunk/lib/tsan/rtl/tsan_sync.cc (original)
> +++ compiler-rt/trunk/lib/tsan/rtl/tsan_sync.cc Tue Jul 8 08:36:59 2014
> @@ -133,7 +133,7 @@ SyncVar* MetaMap::GetAndLock(ThreadState
> u32 myidx = 0;
> SyncVar *mys = 0;
> for (;;) {
> - u32 idx = *meta;
> + u32 idx = idx0;
> for (;;) {
> if (idx == 0)
> break;
> @@ -156,8 +156,10 @@ SyncVar* MetaMap::GetAndLock(ThreadState
> }
> if (!create)
> return 0;
> - if (*meta != idx0)
> + if (*meta != idx0) {
> + idx0 = *meta;
> continue;
> + }
>
> if (myidx == 0) {
> const u64 uid = atomic_fetch_add(&uid_gen_, 1,
> memory_order_relaxed);
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
--
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140708/dcd8e6a9/attachment.html>
More information about the llvm-commits
mailing list