On Mon, Mar 24, 2014 at 7:12 PM, Greg Clayton <[email protected]> wrote:
> > On Mar 24, 2014, at 2:31 AM, Eran Ifrah <[email protected]> wrote: > > > Hi, > > > > Let me first explain what I am trying to do here: > > 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 > > in matter of days. > > > > However, I have encountered yet another annoyance: > > > > 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. > > The LLDB plugin initialization includes this line: > > > > lldb::SBDebugger::Initialize(); > > > > However, this line will work properly unless I have started codelite in > the background :P > > > > So by starting codelite like this: > > $codelite & > > > > LLDB will cause codelite process to 'stop' (the backtrace goes deep into > libpython terminal initialization) > > 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) > > > > The same can be observed when starting lldb in the background (i.e. you > will get the same backtrace): > > $lldb& > > > > > > Any ideas on how to overcome this? Maybe building lldb without python > support? > > 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: > > ScriptInterpreterPython::InitializePrivate() > > I see the same issue on MacOSX: > > 9396 Thread_4108442 DispatchQueue_1: com.apple.main-thread (serial) > 9396 start (in libdyld.dylib) + 1 [0x7fff8eb175fd] > 9396 main (in lldb) + 27 [0x107a1720f] > 9396 lldb_private::Initialize() (in LLDB) + 268 [0x108b66c2c] > 9396 > lldb_private::ScriptInterpreterPython::InitializePrivate() (in LLDB) + 742 > [0x108c8da42] > 9396 lldb_private::TerminalState::Restore() const (in LLDB) > + 74 [0x108c69268] > 9396 tcsetattr (in libsystem_c.dylib) + 114 > [0x7fff8f7485a9] > 9396 ioctl (in libsystem_kernel.dylib) + 159 > [0x7fff96508b00] > 9396 __ioctl (in libsystem_kernel.dylib) + 10 > [0x7fff9650a24a] > > Yes, sorry - I forgot to paste the backtrace. But its identical to what I was experiencing > So the issue seems to be with the: > > TerminalState stdin_tty_state; > stdin_tty_state.Save(STDIN_FILENO, false); > > and it locks up when we call: > > > stdin_tty_state.Restore(); > > 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: > > TerminalState stdin_tty_state2; > stdin_tty_state2.Save(STDIN_FILENO, false); > > 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. > > I will try this ( first I need to build lldb/llvm/clang in debug mode ...) > > > > > > P.S: > > > > 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 ;) ) > > * Make sure you application is not blocking any SIGCHLD signals or the > debugger will fail to report the process events correctly ( > SBProcess::WaitForEvent ) > > > 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. > > Hmm, that was not what I meant... I installed my own SIGCHLD (which calls ::waitpid() to retrieve the exit status of a process + avoid zombies) However, since my handler did not call in turn to the original signal handler I encountered this problem. I did not realize that LLDB was relying on it so it was a nightmare to figure this one out ;) 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. > > > > > > > > > > -- > > Eran Ifrah > > Author of codelite, a cross platform open source C/C++ IDE: > http://www.codelite.org > > wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org > > _______________________________________________ > > lldb-dev mailing list > > [email protected] > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > -- Eran Ifrah Author of codelite, a cross platform open source C/C++ IDE: http://www.codelite.org wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
