mac: Add a hack to condition_variable_posix.cc to avoid a crash.

base/synchronization/condition_variable_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/condition_variable.h"
 
 #include <errno.h>
 #include <sys/time.h>
 
 #include "base/logging.h"
@@ skipping 24 matching lines @@
   pthread_condattr_setclock(&attrs, CLOCK_MONOTONIC);
   rv = pthread_cond_init(&condition_, &attrs);
   pthread_condattr_destroy(&attrs);
 #else
   rv = pthread_cond_init(&condition_, NULL);
 #endif
   DCHECK_EQ(0, rv);
 }
 
 ConditionVariable::~ConditionVariable() {
+#if defined(OS_MACOSX)
+  // This hack is necessary to avoid a fatal pthreads subsystem bug in the
+  // Darwin kernel. http://crbug.com/517681.
+  {

[Mark Mentovai, 2015/09/04 12:30:56]

The bug says 10.10 and 10.11. Does this happen on earlier releases? If not,
would it be beneficial to avoid this on earlier releases?

[erikchen, 2015/09/04 17:25:37]

It does - the comment was looking only at the most recent crashes.
Unfortunately, it's hard to look at the full history since there have been other
bugs with similar signatures and the signatures have changed slightly over time.

The bug report in the apple forums was produced on OSX 10.9, so we know it goes
back at least that far. When looking at the source for 10.8.5, the radar comment
was not present in the source. I don't know if the bug didn't exist, or it just
hadn't been discovered yet. I think it's safer to assume the latter.

+    base::Lock lock;

[Mark Mentovai, 2015/09/04 12:30:56]

How do we know that the memory used for this mutex has never been used for a
condition variable? (Some condition variable beyond our control without this
workaround, that is.) The forum post said that mutex allocation would fail.

[erikchen, 2015/09/04 17:25:37]

We could, soon after each new thread is created, make a lock and reuse it only
on the thread, only for this purpose. But even that wouldn't fully fix the
problem, since we have no guarantees about which memory has or has not been used
for condition variables if the thread is created late in the life cycle of the
application. I believe that this solution solves the problem sufficiently well,
and if it doesn't, we can take another look.

+    base::AutoLock l(lock);
+    struct timespec ts;
+    ts.tv_sec = 0;
+    ts.tv_nsec = 1;
+    pthread_cond_timedwait_relative_np(&condition_, lock.lock_.native_handle(),
+                                       &ts);
+  }
+#endif
+
   int rv = pthread_cond_destroy(&condition_);
   DCHECK_EQ(0, rv);
 }
 
 void ConditionVariable::Wait() {
   base::ThreadRestrictions::AssertWaitAllowed();
 #if !defined(NDEBUG) || defined(DCHECK_ALWAYS_ON)
   user_lock_->CheckHeldAndUnmark();
 #endif
   int rv = pthread_cond_wait(&condition_, user_mutex_);
@@ skipping 58 matching lines @@
   int rv = pthread_cond_broadcast(&condition_);
   DCHECK_EQ(0, rv);
 }
 
 void ConditionVariable::Signal() {
   int rv = pthread_cond_signal(&condition_);
   DCHECK_EQ(0, rv);
 }
 
 }  // namespace base