[Lldb-commits] [PATCH] Thread deadlock and termination.

[Greg Clayton]

On Jul 22, 2010, at 9:26 PM, Stephen Wilson wrote:

> 
> The attached communication.patch removes a premature invalidation of a
> threads pthread_t handle, thus avoiding a segfault when calling
> pthread_cancel.  Also, sets m_read_thread_enabled iff the thread is
> actually spawned.

Committed r109227.

> In host.patch a deadlock condition is removed.  A bit of explanation is
> needed: When calling ThreadCancel in Host::WillTerminate
> g_monitor_thread may be blocked on a call to pthread_cond_wait (for
> example, line 640).  Now, by default, when a cancellation request is
> serviced g_monitor_thread will again own the mutex guarding the
> condition variable it was waiting on.  This causes the call to SetValue
> in Host::WillTerminate to hit a deadlock.
> 
> The call to SetValue does not appear to be needed, so removing it solves
> the issue.

Committed r109228.

> Note that the above is in the linux side of the code.  I see similar
> code in source/Host/macosx/Host.mm but am not sure if it is an issue
> there as well.


We are about to remove the global waitpid thread and have anyone that is interested in child process reaping through a modified Host layer where you give it a callback. The host layer will then spawn a new thread just for that process.

The main reason for this change is the waitpid code is happening in a shared library (lldb.so on linux, LLDB.framework on Mac OS X) and is currently being done from a single thread that watches for all child processes (waitpid with -1 as the pid) which we really shouldn't be doing since the program that is using LLDB, say an IDE, might be interested in monitoring its own child processes and we shouldn't be reaping those for them.

So though the issue may exist in the host layer right now, we will be fixing this today in a different way that shouldn't cause the Host API to change, so everything should just work.

Greg Clayton