[lldb-dev] Locking issues on windows

[Malea, Daniel]

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.


Dan


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.cpp
>
>void
>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
>http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev