[lldb-dev] Locking issues on windows

[Samuel Jacob]

I am seeing a locking issue in Ubuntu too. I havent debugged to
confirm whether it is same as the Windows issue.

How to reproduce the issue:
1) /trunk/lldb hello_world_program
2) (lldb) run
3) Hang

Attached gdb and got the following backtrace.

(gdb) bt
#0  0x00007ffff344c53d in pthread_rwlock_wrlock () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007ffff4466135 in lldb_private::ReadWriteLock::WriteLock (this=0x6bfe50)
    at /dbc/pa-dbc1117/jacobs/llvm/tools/lldb/source/Target/../../include/lldb/Host/ReadWriteLock.h:77
#2  0x00007ffff445a07a in lldb_private::Process::PrivateResume
(this=0x6bf500) at
/dbc/pa-dbc1117/jacobs/llvm/tools/lldb/source/Target/Process.cpp:3201
#3  0x00007ffff4459f18 in lldb_private::Process::Resume
(this=0x6bf500) at
/dbc/pa-dbc1117/jacobs/llvm/tools/lldb/source/Target/Process.cpp:1657
#4  0x00007ffff3f20fac in CommandObjectProcessLaunch::DoExecute
(this=0x6383d0, launch_args=..., result=...)
    at /dbc/pa-dbc1117/jacobs/llvm/tools/lldb/source/Commands/CommandObjectProcess.cpp:308
#5  0x00007ffff4166fd0 in lldb_private::CommandObjectParsed::Execute
(this=0x6383d0, args_string=0x7ffff2d264d8 "", result=...)
    at /dbc/pa-dbc1117/jacobs/llvm/tools/lldb/source/Interpreter/CommandObject.cpp:969
#6  0x00007ffff4159896 in
lldb_private::CommandInterpreter::HandleCommand (this=0x6285a0,
command_line=0x7fffe4000e58 "process launch",
    lazy_add_to_history=lldb_private::eLazyBoolYes, result=...,
override_context=0x0, repeat_on_empty_command=true,
no_context_switching=false)
    at /dbc/pa-dbc1117/jacobs/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp:1810
#7  0x00007ffff3e5b714 in lldb::SBCommandInterpreter::HandleCommand
(this=0x7fffffffb600, command_line=0x7fffe4000e58 "process launch",
result=...,
    add_to_history=true) at
/dbc/pa-dbc1117/jacobs/llvm/tools/lldb/source/API/SBCommandInterpreter.cpp:122
#8  0x000000000040d286 in Driver::HandleIOEvent (this=0x7fffffffe2b0,
event=...) at /dbc/pa-dbc1117/jacobs/llvm/tools/lldb/tools/driver/Driver.cpp:1072
#9  0x000000000040ebaa in Driver::MainLoop (this=0x7fffffffe2b0) at
/dbc/pa-dbc1117/jacobs/llvm/tools/lldb/tools/driver/Driver.cpp:1537
#10 0x000000000040f37b in main (argc=2, argv=0x7fffffffe4b8,
envp=0x7fffffffe4d0) at
/dbc/pa-dbc1117/jacobs/llvm/tools/lldb/tools/driver/Driver.cpp:1702

On Wed, 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.
>
> 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
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

On Wed, 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.
>
> 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
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev