[lldb-dev] Locking issues on windows

Malea, Daniel daniel.malea at intel.com
Wed Apr 17 10:34:07 PDT 2013

Carlo, awesome work!

Are your fixes on the Windows branch? If not, could you provide a patch
with your changes? I'd love to try them out to see if it fixes the hangs
in question on Linux. Multiple people seem affected by the problem.


On 2013-04-17 1:18 PM, "Carlo Kok" <ck at remobjects.com> wrote:

>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::ProcessEventData::DoOnRemoval (Event *event_ptr)
>fwiw the changes I mentioned make it balanced.
>Carlo Kok
>lldb-dev mailing list
>lldb-dev at cs.uiuc.edu

More information about the lldb-dev mailing list