Saving and restoring STDIN in the ScriptInterpreter

Hi Pavel, Jonas,

I was trying to reduce a bug through c-reduce, so I decided to write a SBAPI script to make it easier.
I did find out, that after the first iteration, the reduction gets stuck forever.
I sampled the process and I saw the following (trimmed for readability).

Call graph:
                                                            8455 lldb_private::CommandInterpreter::GetScriptInterpreter(bool)  (in + 84  [0x111aff826]
                                                              8455 lldb_private::PluginManager::GetScriptInterpreterForLanguage(lldb::ScriptLanguage, lldb_private::CommandInterpreter&)  (in + 99  [0x111a1efcf]
                                                                8455 lldb_private::ScriptInterpreterPython::CreateInstance(lldb_private::CommandInterpreter&)  (in + 26  [0x111d128f4]
                                                                  8455 std::__1::shared_ptr<lldb_private::ScriptInterpreterPython> std::__1::shared_ptr<lldb_private::ScriptInterpreterPython>::make_shared<lldb_private::CommandInterpreter&>(lldb_private::CommandInterpreter&&&)  (in + 72  [0x111d1b976]
                                                                    8455 lldb_private::ScriptInterpreterPython::ScriptInterpreterPython(lldb_private::CommandInterpreter&)  (in + 353  [0x111d11ff3]
                                                                      8455 lldb_private::ScriptInterpreterPython::InitializePrivate()  (in + 494  [0x111d12594]
                                                                        8455 (anonymous namespace)::InitializePythonRAII::~InitializePythonRAII()  (in + 146  [0x111d1b446]
                                                                          8455 lldb_private::TerminalState::Restore() const  (in + 74  [0x111ac8268]
                                                                            8455 tcsetattr  (in libsystem_c.dylib) + 110  [0x7fff7b95b585]
                                                                              8455 ioctl  (in libsystem_kernel.dylib) + 151  [0x7fff7ba19b44]
                                                                                8455 __ioctl  (in libsystem_kernel.dylib) + 10  [0x7fff7ba19b5a]

It looks like lldb gets stuck forever in tcsetattr(), and there are no other threads waiting so it’s not entirely obvious to me why it’s waiting there.
I was never able to reproduce this with an interactive session, I suspect this is somehow related to the fact that c-reduce spawns a thread in the background, hence it doesn’t have a TTY associated.
I looked at the code that does this, and I wasn’t really able to find a reason why we need to do this work. Jim thinks it might have been needed historically.
git blame doesn’t really help that much either. If I remove the code, everything still passes and it’s functional, but before moving forward with this I would like to collect your opinions.

$ git diff
diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index ee94a183e0d…c53b3bd0fb6 100644
— a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -224,10 +224,6 @@ struct InitializePythonRAII {
: m_gil_state(PyGILState_UNLOCKED), m_was_already_initialized(false) {

  • // Python will muck with STDIN terminal state, so save off any current TTY
  • // settings so we can restore them.
  • m_stdin_tty_state.Save(STDIN_FILENO, false);

Hi Davide,

I believe your guess about background processes is correct. I think that
the lldb process is stopped (or is continually getting stopped and
restarted) by SIGTTOU.