Assert on deleting a held lock.

base/synchronization/lock.cc

Index: base/synchronization/lock.cc
diff --git a/base/synchronization/lock.cc b/base/synchronization/lock.cc
index 6445ce8a853d591bb3a8a2aca63ef0fa2f6b796b..c47441e71f3e2f2f14abb6607dbb82e96fb21963 100644
--- a/base/synchronization/lock.cc
+++ b/base/synchronization/lock.cc
@@ -13,9 +13,19 @@
 
 namespace base {
 
+const PlatformThreadId kNoThreadId = static_cast<PlatformThreadId>(0);
+
 Lock::Lock() : lock_() {
   owned_by_thread_ = false;
-  owning_thread_id_ = static_cast<PlatformThreadId>(0);
+  owning_thread_id_ = kNoThreadId;
+}
+
+Lock::~Lock() {
+  DCHECK(!owned_by_thread_);
+  DCHECK_EQ(kNoThreadId, owning_thread_id_);
+
+  // This may trip the assert on unlock in the owning thread.

[willchan no longer on Chromium, 2013/04/08 15:28:13]

I don't understand this one. We know that it's false already due to the new
DCHECK on line 24, right?

[Sigurður Ásgeirsson, 2013/04/08 15:32:35]

Depends on whether the DCHECK is set to log fatally, it seems in some builds
and/or on some bots we just spew a stack trace and move on. In a build with
those settings, you *may* get a second stack trace as e.g. AssertAcquired and/or
CheckHeldAndUnmark are invoked on the owning thread as part of unlocking. It
depends on whether the lock is e.g. a static instance, and if not, on what
happens to the allocation afterwards.
This is definitely heuristic, though - I'll remove it if you think it has no
value?

+  owned_by_thread_ = false;
 }
 
 void Lock::AssertAcquired() const {