[Lldb-commits] m_private_run_lock relying on undefined pthread behaviour

[Greg Clayton]

If we are going to check this it we will need to make sure the underlying function that does the WriteUnlock/WriteLock checks for EINTR being returned (if the pthread_rwlock_wrlock/pthread_rwlock_trywrlock/pthread_rwlock_unlock can return EINTR) and repeat the calls to these lock/unlock functions...

On Jun 21, 2013, at 10:03 AM, Ed Maste <emaste at freebsd.org> wrote:

> 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)