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)
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
