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

[Greg Clayton]

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]

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.

> 
> 
> 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.

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