[PATCH] D20427: [tsan] Don't abort when a deadlock detector finds a mutex cycle longer than 10
Dmitry Vyukov via llvm-commits
llvm-commits at lists.llvm.org
Thu May 19 08:25:04 PDT 2016
dvyukov added inline comments.
================
Comment at: lib/sanitizer_common/sanitizer_deadlock_detector1.cc:125
@@ +124,3 @@
+ if (len == 0U) {
+ // Hm.. cycle of 10 locks? I'd like to see that.
+ return;
----------------
kubabrecka wrote:
> dvyukov wrote:
> > So, can we see it? :)
> > Maybe there is just some bug in logic, or a false deadlock report? Is it actually a legit report?
> > If it is a true report, then we should consider increasing the limit (and then we don't need to remove the CHECK). If it is a false report, then we need to fix something (and again no need to remove the CHECK, let it catch more bugs).
> It looks to me the report is correct (and it's really a long cycle). In this case it's a collection of Obj-C objects using `@synchronized(self)` while also referring to other objects. The same issue gets reported multiple times with different cycle lengths, so the report with extremely long cycle isn't really useful (it's already reported with simpler cases). Anyway, increasing the limit works for me as well.
Let's increase the number to, say, 20 then.
As for the CHECK, we can leave it as is, or maybe replace with just Printf. If you get 13, I guess somebody can get 21. But I think it's better to have just a Printf, so that users see at least something.
http://reviews.llvm.org/D20427
More information about the llvm-commits
mailing list