[Lldb-commits] [PATCH] fix lldb-mi hang on OSX

Zachary Turner zturner at google.com
Tue Dec 2 08:27:59 PST 2014 

Side comment, But regarding conditionally compiling the file, i prefer
doing that at the CMake level (only include it in the set of inputs if the
platform is correct) instead of wrapping the whole file in ifdefs.
On Tue, Dec 2, 2014 at 3:25 AM Abid, Hafiz <Hafiz_Abid at mentor.com> wrote:

> Some more comments.
>
> It seems that select makes it very slow. Running lldb-mi tests takes
> double the time. So it is probably not an option. Code with ioctl seems to
> work ok on Linux although I had to add an include. I also built it with
> mingw and tried it on windows and did not see anything obviously wrong. I
> also had one other thought. What do you think of creating a derived class
> of ' CMICmnStreamStdinLinux' for OSX and overriding InputAvailable in it.
> If that seems too much work for it then I am ok with committing this patch
> with modification described above.
>
> Also I think that this whole file should be compiled conditionally as it
> is not used on windows instead of putting many #ifdefs.
>
> Thanks,
> Abid
>
>
> > -----Original Message-----
> > From: dawn at burble.org [mailto:dawn at burble.org]
> > Sent: 02 December 2014 09:58
> > To: Abid, Hafiz
> > Cc: colin at codeplay.com; deepak at codeplay.com; lldb-commits at cs.uiuc.edu
> > Subject: Re: [Lldb-commits] [PATCH] fix lldb-mi hang on OSX
> >
> > Thank you for reviewing!
> >
> > On Fri, Nov 28, 2014 at 10:02:33AM +0000, Abid, Hafiz wrote:
> > > Hi Dawn,
> > > I looked at the patch a bit. It looks ok to use select to check if the
> input is
> > available before blocking on fgets. But I am still wondering why you need
> > extra "return" in case of -exec-run. It seems to work ok on Linux. Where
> is it
> > blocking in OSX? Btw, if the problem is only with gdb-exit then an extra
> check
> > for it where we check for "quit" will work too.
> >
> > I can't explain why it works on Linux (although I assumed it must), but
> on
> > OSX, if you attach you'll see that it is waiting on a mutex.  You can
> see where
> > in the following example:
> >
> > debug session in lldb-mi showing hang after -exec-run:
> >     yippie:~/llvm_trunk$$LLDBMI_EXEC --interpreter
> >     (gdb)
> >     -file-exec-and-symbols ~/tmp/a.out
> >     ^done
> >     -break-insert -f main
> >     =breakpoint-
> > modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",ad
> > dr="0xffffffff",func="main",file="x.cpp",fullname="/Users/
> dawn/tmp/x.cpp",li
> > ne="5",pending=["main"],times="0",original-location="main"}
> >
> > ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr=
> > "0xffffffff",func="main",file="x.cpp",fullname="/Users/dawn/
> tmp/x.cpp",line=
> > "5",pending=["main"],times="1",original-location="main"}
> >     -exec-run
> >
> > attaching to lldb-mi to see what's up:
> >     yippie:~/cppstd/source$~/llvm_delphi/build_ninja/bin/lldb
> >     (lldb) attach 27893
> >     Process 27893 stopped
> >     * thread #1: tid = 0xf7a813, 0x00007fff90dad746
> > libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-
> > thread', stop reason = signal SIGSTOP
> >       frame #0: 0x00007fff90dad746
> > libsystem_kernel.dylib`__psynch_mutexwait + 10
> >     -> 0x7fff90dad746 <__psynch_mutexwait+10>: jae    0x7fff90dad750
> > ; __psynch_mutexwait + 20
> >     0x7fff90dad748 <__psynch_mutexwait+12>: movq   %rax, %rdi
> >     0x7fff90dad74b <__psynch_mutexwait+15>: jmp    0x7fff90daa175
>     ;
> > cerror_nocancel
> >     0x7fff90dad750 <__psynch_mutexwait+20>: retq
> >
> >     Executable module set to "/Users/dawn/llvm_trunk/build_
> ninja/bin/lldb-
> > mi".
> >     Architecture set to: x86_64-apple-macosx.
> >     (lldb) bt
> >     * thread #1: tid = 0xf7a813, 0x00007fff90dad746
> > libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-
> > thread', stop reason = signal SIGSTOP
> >     * frame #0: 0x00007fff90dad746
> > libsystem_kernel.dylib`__psynch_mutexwait + 10
> >       frame #1: 0x00007fff8f51b779
> > libsystem_pthread.dylib`_pthread_mutex_lock + 372
> >       frame #2: 0x00007fff92ea5edd libsystem_c.dylib`flockfile + 37
> >       frame #3: 0x00007fff92ea6e74 libsystem_c.dylib`fileno + 15
> >       frame #4: 0x0000000107dff2b8
> > liblldb.3.6.0.dylib`lldb_private::File::GetDescriptor(
> this=0x00007fe9b94420d8)
> > const + 88 at File.cpp:146
> >       frame #5: 0x0000000107ec557c
> > liblldb.3.6.0.dylib`lldb_private::IOHandler::GetInputFD(this=
> 0x00007fe9b965f
> > 4d0) + 92 at IOHandler.cpp:85
> >       frame #6: 0x00000001082831b8
> > liblldb.3.6.0.dylib`IOHandlerProcessSTDIO(this=0x00007fe9b965f4d0,
> > process=0x00007fe9ba031800, write_fd=5) + 184 at Process.cpp:4910
> >       frame #7: 0x00000001082797c3
> > liblldb.3.6.0.dylib`IOHandlerProcessSTDIO(this=0x00007fe9b965f4d0,
> > process=0x00007fe9ba031800, write_fd=5) + 35 at Process.cpp:4911
> >       frame #8: 0x000000010826df42
> > liblldb.3.6.0.dylib`lldb_private::Process::SetSTDIOFileDescriptor(this=
> 0x00007f
> > e9ba031800, fd=5) + 642 at Process.cpp:5100
> >       frame #9: 0x000000010824fd8e
> > liblldb.3.6.0.dylib`lldb_private::Platform::DebugProcess(this=
> 0x00007fe9b952
> > 8c10, launch_info=0x00007fff598962a8, debugger=0x00007fe9b9870c00,
> > target=0x00007fe9b9880000, error=0x00007fff59896270) + 1406 at
> > Platform.cpp:1138
> >       frame #10: 0x00000001085349f4
> > liblldb.3.6.0.dylib`PlatformPOSIX::DebugProcess(this=0x00007fe9b9528c10,
> > launch_info=0x00007fff598962a8, debugger=0x00007fe9b9870c00,
> > target=0x00007fe9b9880000, error=0x00007fff59896270) + 244 at
> > PlatformPOSIX.cpp:875
> >       frame #11: 0x00000001082cfde8
> > liblldb.3.6.0.dylib`lldb_private::Target::Launch(this=
> 0x00007fe9b9880000,
> > launch_info=0x00007fff598962a8, stream=0x0000000000000000) + 1944 at
> > Target.cpp:2462
> >       frame #12: 0x0000000108672c58
> > liblldb.3.6.0.dylib`lldb::SBTarget::Launch(this=0x0000000106469178,
> > listener=0x0000000106469400, argv=0x0000000000000000,
> > envp=0x0000000000000000, stdin_path=0x0000000000000000,
> > stdout_path=0x0000000000000000, stderr_path=0x0000000000000000,
> > working_directory=0x0000000000000000, launch_flags=2,
> > stop_at_entry=false, error=0x00007fff59896838) + 2088 at SBTarget.cpp:779
> >       frame #13: 0x00000001063aabea lldb-
> > mi`CMICmdCmdExecRun::Execute(this=0x00007fe9ba851200) + 234 at
> > MICmdCmdExec.cpp:94
> >       frame #14: 0x00000001063ab3cc lldb-mi`non-virtual thunk to
> > CMICmdCmdExecRun::Execute(this=0x00007fe9ba851240) + 28 at
> > MICmdCmdExec.cpp:113
> >       frame #15: 0x00000001063e5230 lldb-
> > mi`CMICmdInvoker::CmdExecute(this=0x00000001064688e0,
> > vCmd=0x00007fe9ba851200) + 272 at MICmdInvoker.cpp:216
> >       frame #16: 0x00000001063ea1b4 lldb-
> > mi`CMICmdMgr::CmdExecute(this=0x00000001064698a0,
> > vCmdData=0x00007fff598976b8) + 804 at MICmdMgr.cpp:211
> >       frame #17: 0x0000000106434ea6 lldb-
> > mi`CMIDriver::ExecuteCommand(this=0x0000000106468bc0,
> > vCmdData=0x00007fff598976b8) + 38 at MIDriver.cpp:1057
> >       frame #18: 0x0000000106433e23 lldb-
> > mi`CMIDriver::InterpretCommandThisDriver(this=0x0000000106468bc0,
> > vTextLine=0x00007fff59897d68, vwbCmdYesValid=0x00007fff59897cff) + 195
> > at MIDriver.cpp:1009
> >       frame #19: 0x0000000106433477 lldb-
> > mi`CMIDriver::InterpretCommand(this=0x0000000106468bc0,
> > vTextLine=0x00007fff59897d68) + 55 at MIDriver.cpp:973
> >       frame #20: 0x00000001064332eb lldb-
> > mi`CMIDriver::ReadStdinLineQueue(this=0x0000000106468bc0) + 651 at
> > MIDriver.cpp:690
> >       frame #21: 0x0000000106432f9f lldb-
> > mi`CMIDriver::DoMainLoop(this=0x0000000106468bc0) + 447 at
> > MIDriver.cpp:630
> >       frame #22: 0x000000010643342c lldb-mi`non-virtual thunk to
> > CMIDriver::DoMainLoop(this=0x0000000106468c00) + 28 at MIDriver.cpp:647
> >       frame #23: 0x0000000106442722 lldb-
> > mi`CMIDriverMgr::DriverMainLoop(this=0x0000000106469500) + 66 at
> > MIDriverMgr.cpp:344
> >       frame #24: 0x0000000106440311 lldb-mi`main(argc=2,
> > argv=0x00007fff59898308) + 321 at MIDriverMain.cpp:352
> >       frame #25: 0x00007fff8b32a5fd libdyld.dylib`start + 1
> >       frame #26: 0x00007fff8b32a5fd libdyld.dylib`start + 1
> >     (lldb)
> >
> >
> >
> > I've offered to make the patch OSX-specific if that is preferred?
> >
> > Thanks,
> > -Dawn
>
>
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20141202/19d5be13/attachment.html>

More information about the lldb-commits mailing list