[lldb-dev] Locking issues on windows

[Carlo Kok]

I'm trying to update the Windows branch to the latest and greatest and 
found these locking issues (not sure if they're relevant for posix too):

When I attach a process (I only use the gdb remote) the first even I get 
is "stopped" which tries to unlock m_private_run_lock, however this one 
is never locked in the first place. Windows' writelock doesn't 
appreciate that; as a workaround I added a
m_private_run_lock.WriteLock(); in Process' constructor, which seems to 
fix that.

The second issue occurs when when trying to cause a "Stop" when it's 
already paused on internal breakpoints; for me this is during slow 
symbol load. When happens is that the loading (which happens from within 
Process::ShouldBroadcastEvent) resumes it, then the process exits 
properly (triggers the ShouldBroadcastEvent again) however:

ProcessEventData::DoOnRemoval(lldb_private::Event * event_ptr)
called by Listener::FindNextEventInternal.

The resume call is in this condition:
   if (state != eStateRunning)

Changing that to:
lldb::StateType state = m_process_sp->GetPrivateState();
if (state != eStateRunning && state != eStateCrashed && state != 
eStateDetached && state != eStateExited)

Seems to fix it, as there's no reason to try & resume a process that's 
not running in the first place (and since exiting doesn't unlock a 
process this causes a deadlock)

The last issue is this:
void * Process::RunPrivateStateThread ()
does : m_public_run_lock.WriteUnlock(); when it's done. The Finalize 
also unlocks that same lock, which Windows crashes on.
commenting that out and it seems to work stable.


Anyone see any issues in all of this? (might make sense to apply this to 
trunk too; it's never good to have unbalanced lock/unlocks)