[lldb-dev] Locking issues on windows

[Carlo Kok]

Op 17-4-2013 18:47, Greg Clayton schreef:
>
> On Apr 17, 2013, at 1:27 AM, Carlo Kok <ck at remobjects.com> 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