[Lldb-commits] m_private_run_lock relying on undefined pthread behaviour

[Greg Clayton]

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.

Greg

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

> On FreeBSD lldb currently hangs for me when trying to launch a
> process; it gets stuck in the m_private_run_lock.WriteLock() in
> Process::SetPrivateState().  After digging into this a bit it appears
> to be due to the lock relying on undefined behaviour in
> pthread_rwlock_unlock().
> 
> POSIX used to require EPERM for the case of calling unlock on a lock
> not held by the current thread, but this has now been downgraded to
> undefined behaviour[1].  AFAICT both Linux and OS X allow a lock from
> one thread and unlock from another, but FreeBSD fails with EPERM, and
> the m_private_run_lock fails to be unlocked.  Then the subsequent lock
> call hangs.
> 
> I'm not sure if the locking & unlocking from different threads is
> fundamental to the way lldb operates; if so, I suspect it's fairly
> straightforward to migrate to a different locking strategy.  I can
> have a go at implementing that but I hope to get feedback from someone
> familiar with this first.
> 
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_unlock.html
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits