(tiny) Temporarily disable lock instrumentation

base/synchronization/lock_impl_posix.cc

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "base/synchronization/lock_impl.h"
 
 #include <errno.h>
 #include <string.h>
 
-#include "base/debug/activity_tracker.h"
 #include "base/logging.h"
 #include "base/synchronization/lock.h"
 
 namespace base {
 namespace internal {
 
 // Determines which platforms can consider using priority inheritance locks. Use
 // this define for platform code that may not compile if priority inheritance
 // locks aren't available. For this platform code,
 // PRIORITY_INHERITANCE_LOCKS_POSSIBLE() is a necessary but insufficient check.
@@ skipping 32 matching lines @@
   DCHECK_EQ(rv, 0) << ". " << strerror(rv);
 }
 
 bool LockImpl::Try() {
   int rv = pthread_mutex_trylock(&native_handle_);
   DCHECK(rv == 0 || rv == EBUSY) << ". " << strerror(rv);
   return rv == 0;
 }
 
 void LockImpl::Lock() {
-  base::debug::ScopedLockAcquireActivity lock_activity(this);

[bcwhite, 2016/10/04 20:31:00]

You can leave this.  It's only Windows that causes the recursion.

[manzagop (departed), 2016/10/04 20:34:53]

Done.

   int rv = pthread_mutex_lock(&native_handle_);
   DCHECK_EQ(rv, 0) << ". " << strerror(rv);
 }
 
 void LockImpl::Unlock() {
   int rv = pthread_mutex_unlock(&native_handle_);
   DCHECK_EQ(rv, 0) << ". " << strerror(rv);
 }
 
 // static
@@ skipping 15 matching lines @@
   //     Fixed in glibc 2.17.
   //     Priority inheritance mutexes may deadlock with condition variables
   //     during recacquisition of the mutex after the condition variable is
   //     signalled.
   return false;
 #endif
 }
 
 }  // namespace internal
 }  // namespace base