LLDB causes application to 'stopped'

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 :stuck_out_tongue:

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?

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 :wink: )

  • Make sure you application is not blocking any SIGCHLD signals or the debugger will fail to report the process events correctly ( SBProcess::WaitForEvent )

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 :stuck_out_tongue:

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 :wink: )
* 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.

> 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 :stuck_out_tongue:
>
> 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 :wink: )
> * 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 :wink:

I am glad you figured this out, and we should look at a way to make sure

Hello Greg,

I tried as you suggested and copared the various flags (what I could see in the debugger) and nothing is modified from the first call to:

stdin_tty_state.Save(STDIN_FILENO, false); (ScriptInterpreterPython.cpp, 2527)

until the last call to stdin_tty_state.Restore()

commenting this line (“stdin_tty_state.Restore()”) fixes the problem for me.
I also played a bit with lldb from the command line and it seems fine to me :wink:

Eran