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