[Lldb-commits] m_private_run_lock relying on undefined pthread behaviour
Greg Clayton
gclayton at apple.com
Fri Jun 21 18:35:10 PDT 2013
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)
More information about the lldb-commits
mailing list