[lldb-dev] LLDB causes application to 'stopped'

[Eran Ifrah]

On Mon, Mar 24, 2014 at 7:12 PM, Greg Clayton <gclayton at apple.com> wrote:

>
> On Mar 24, 2014, at 2:31 AM, Eran Ifrah <eran.ifrah at gmail.com> 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
> > lldb-dev at cs.uiuc.edu
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140324/3f810f1d/attachment.html>