Op 17-4-2013 18:47, Greg Clayton schreef:
On Apr 17, 2013, at 1:27 AM, Carlo Kok <[email protected]> wrote:
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.
We need to fix this better by locking the private run lock when attaching if
all goes well.
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)
Where is the above "if (state != eStateRunning)"?
Process.cpp
void
Process::ProcessEventData::DoOnRemoval (Event *event_ptr)
fwiw the changes I mentioned make it balanced.
--
Carlo Kok
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
