<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 24, 2014 at 7:12 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
On Mar 24, 2014, at 2:31 AM, Eran Ifrah <<a href="mailto:eran.ifrah@gmail.com">eran.ifrah@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> Let me first explain what I am trying to do here:<br>
> I have written an LLDB plugin for codelite IDE which so far supports limited functionality, but as soon as I will overcome all the small distractions, I expect it to be fully functional<br>
> in matter of days.<br>
><br>
> However, I have encountered yet another annoyance:<br>
><br>
> The plugin is hosted within codelite (plugins are shared objects). On startup, codelite loads all the plugins available for it and calls their initialization method.<br>
> The LLDB plugin initialization includes this line:<br>
><br>
> lldb::SBDebugger::Initialize();<br>
><br>
> However, this line will work properly unless I have started codelite in the background :P<br>
><br>
> So by starting codelite like this:<br>
> $codelite &<br>
><br>
> LLDB will cause codelite process to 'stop' (the backtrace goes deep into libpython terminal initialization)<br>
> bringing codelite to the foreground fixes this (you can now put codelite in the background once again without any problems, since we passed the 'Initialize' phase)<br>
><br>
> The same can be observed when starting lldb in the background (i.e. you will get the same backtrace):<br>
> $lldb&<br>
><br>
><br>
> Any ideas on how to overcome this? Maybe building lldb without python support?<br>
<br>
</div>The python support is one of the biggest strengths of LLDB and allows a lot of great things to be done. I would suggest trying to figure out what is going on and I am guessing things are going to be locking up within the following function:<br>
<br>
ScriptInterpreterPython::InitializePrivate()<br>
<br>
I see the same issue on MacOSX:<br>
<br>
9396 Thread_4108442 DispatchQueue_1: com.apple.main-thread (serial)<br>
9396 start (in libdyld.dylib) + 1 [0x7fff8eb175fd]<br>
9396 main (in lldb) + 27 [0x107a1720f]<br>
9396 lldb_private::Initialize() (in LLDB) + 268 [0x108b66c2c]<br>
9396 lldb_private::ScriptInterpreterPython::InitializePrivate() (in LLDB) + 742 [0x108c8da42]<br>
9396 lldb_private::TerminalState::Restore() const (in LLDB) + 74 [0x108c69268]<br>
9396 tcsetattr (in libsystem_c.dylib) + 114 [0x7fff8f7485a9]<br>
9396 ioctl (in libsystem_kernel.dylib) + 159 [0x7fff96508b00]<br>
9396 __ioctl (in libsystem_kernel.dylib) + 10 [0x7fff9650a24a]<br>
<br></blockquote><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Yes, sorry - I forgot to paste the backtrace. But its identical to what I was experiencing</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So the issue seems to be with the:<br>
<br>
TerminalState stdin_tty_state;<br>
stdin_tty_state.Save(STDIN_FILENO, false);<br>
<br>
and it locks up when we call:<br>
<br>
<br>
stdin_tty_state.Restore();<br>
<br>
You might run this in the foreground and see exactly what is saved during the call to stdin_tty_state.Save(...) and then add another:<br>
<br>
TerminalState stdin_tty_state2;<br>
stdin_tty_state2.Save(STDIN_FILENO, false);<br>
<br>
Then compare what is in stdin_tty_state with stdin_tty_state2 and see if python modified anything in the terminal states. If they are the same, we can probably skip these calls and avoid this issue.<br>
<div class=""><br></div></blockquote><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">I will try this ( first I need to build lldb/llvm/clang in debug mode ...)</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
><br>
><br>
> P.S:<br>
><br>
> Other annoyance I encountered which might worth written to this mailing list (so at least they can be archived so other people might find them while googling ;) )<br>
> * Make sure you application is not blocking any SIGCHLD signals or the debugger will fail to report the process events correctly ( SBProcess::WaitForEvent )<br>
<br>
<br>
</div>How do you have an IDE that doesn't reap child processes? IDEs will kick off compilers and linkers and many other child processes and if you aren't reaping them you are creating zombies.<br>
<br></blockquote><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Hmm, that was not what I meant...</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">
I installed my own SIGCHLD (which calls ::waitpid() to retrieve the exit status of a process + avoid zombies)</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">
However, since my handler did not call in turn to the original signal handler I encountered this problem.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">I did not realize that LLDB was relying on it so it was a nightmare to figure this one out ;)</div>
<div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am glad you figured this out, and we should look at a way to make sure SIGCHILD isn't set to ignore and warn when launching child processes from within LLDB.<br>
<div class=""><br>
<br>
><br>
><br>
><br>
> --<br>
> Eran Ifrah<br>
> Author of codelite, a cross platform open source C/C++ IDE: <a href="http://www.codelite.org" target="_blank">http://www.codelite.org</a><br>
> wxCrafter, a wxWidgets RAD: <a href="http://wxcrafter.codelite.org" target="_blank">http://wxcrafter.codelite.org</a><br>
</div>> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Eran Ifrah<br>Author of codelite, a cross platform open source C/C++ IDE: <a href="http://www.codelite.org" target="_blank">http://www.codelite.org</a><br>
<div>wxCrafter, a wxWidgets RAD: http://<a href="http://wxcrafter.codelite.org" target="_blank">wxcrafter.codelite.org</a></div></div>
</div></div>