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

base/synchronization/condition_variable_posix.cc

Index: base/synchronization/condition_variable_posix.cc
diff --git a/base/synchronization/condition_variable_posix.cc b/base/synchronization/condition_variable_posix.cc
index 013284c888f72993b81a75f0b56a28bd653e6e3a..c9a2ec43f829e7fdbb73351e8739ad5e699150eb 100644
--- a/base/synchronization/condition_variable_posix.cc
+++ b/base/synchronization/condition_variable_posix.cc
@@ -42,6 +42,20 @@ ConditionVariable::ConditionVariable(Lock* user_lock)
 }
 
 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);
 }