[Lldb-commits] m_private_run_lock relying on undefined pthread behaviour

[Ed Maste]

On 18 June 2013 18:45, Greg Clayton <gclayton at apple.com> wrote:
> Yes we do rely upon being able to lock on one thread and unlock on another. Good catch, let us know what you come up with.

For now I have just hacked my thread library to avoid returning EPERM
for this case to move farther along, and will ponder a solution for
this.  Any objection to the following change for now, to abort instead
of deadlocking in this case?

diff --git a/source/Target/Process.cpp b/source/Target/Process.cpp
index c6945dc..059955e 100644
--- a/source/Target/Process.cpp
+++ b/source/Target/Process.cpp
@@ -1715,10 +1715,12 @@ Process::SetPrivateState (StateType new_state)
     const bool new_state_is_stopped = StateIsStoppedState(new_state, false);
     if (old_state_is_stopped != new_state_is_stopped)
     {
+        bool rv;
         if (new_state_is_stopped)
-            m_private_run_lock.WriteUnlock();
+            rv = m_private_run_lock.WriteUnlock();
         else
-            m_private_run_lock.WriteLock();
+            rv = m_private_run_lock.WriteLock();
+        assert(rv);
     }

     if (state_changed)