[Lldb-commits] [PATCH] fix lldb-mi hang on OSX
Ilia K
ki.stfu at gmail.com
Tue Dec 2 06:51:46 PST 2014
Hi Abid,
>RE: What do you think of creating a derived class of '
CMICmnStreamStdinLinux' for OSX and overriding InputAvailable in it.
May be it's a good decision because I saw few files in lldb-mi with "Osx"
suffixes. But creation of derived class shouldn't work. There are few
problems:
* CMICmnStreamStdinLinux has private ctors & dtor. Therefore, to be
derived from this class I added "friend CMICmnStreamStdinOsx" in
CMICmnStreamStdinLinux declaration. May be it's not significant.
* CMICmnStreamStdinLinux is derived from
MI::ISingleton<CMICmnStreamStdinLinux> so CMICmnStreamStdinOsx is derived
from it also. Therefore Instance() method wouldn't work and as you know we
can't use both CMICmnStreamStdinLinux and
MI::ISingleton<CMICmnStreamStdinOsx> as base classes.
I don't think that copy-paste more than 200 lines of code is wise
(bugfixing and so on), but if so, I attached a patch (see
lldbmi_hang_fix_via_select.v2.patch). Of course we could do some
CMICmnStreamStdinUnix class, which will be base class for
CMICmnStreamStdinLinux & CMICmnStreamStdinOsx, or we could just wrap
InputAvailable code into ifdef-endif block.
Btw, pay attention to my letter here please:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20141201/014285.html
Thanks,
Ilia
On Tue, Dec 2, 2014 at 2:24 PM, 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/d5e1347d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lldbmi_hang_fix_via_select.v2.patch
Type: application/octet-stream
Size: 11789 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20141202/d5e1347d/attachment.obj>
More information about the lldb-commits
mailing list