[all-commits] [llvm/llvm-project] 049ae9: [lldb] Fix that the embedded Python REPL crashes i...

[Jonas Devlieghere via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 049ae93097c0c6f7cef6294f16c7f6de9138cd6d
      https://github.com/llvm/llvm-project/commit/049ae93097c0c6f7cef6294f16c7f6de9138cd6d
  Author: Jonas Devlieghere <jonas at devlieghere.com>
  Date:   2022-01-13 (Thu, 13 Jan 2022)

  Changed paths:
    M lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
    A lldb/test/API/iohandler/sigint/TestIOHandlerPythonREPLSigint.py

  Log Message:
  -----------
  [lldb] Fix that the embedded Python REPL crashes if it receives SIGINT

When LLDB receives a SIGINT while running the embedded Python REPL it
currently just crashes in ScriptInterpreterPythonImpl::Interrupt with an
error such as the one below:

  Fatal Python error: PyThreadState_Get: the function must be called
  with the GIL held, but the GIL is released (the current Python thread
  state is NULL)

The faulty code that causes this error is this part of
ScriptInterpreterPythonImpl::Interrupt:

  PyThreadState *state = PyThreadState_GET();
  if (!state)
    state = GetThreadState();
  if (state) {
    long tid = state->thread_id;
    PyThreadState_Swap(state);
    int num_threads = PyThreadState_SetAsyncExc(tid, PyExc_KeyboardInterrupt);

The obvious fix I tried is to just acquire the GIL before this code is
running which fixes the crash but the KeyboardInterrupt we want to raise
immediately is actually just queued and would only be raised once the
next line of input has been parsed (which e.g. won't interrupt Python
code that is currently waiting on a timer or IO from what I can see).
Also none of the functions we call here is marked as safe to be called
from a signal handler from what I can see, so we might still end up
crashing here with some bad timing.

Python 3.2 introduced PyErr_SetInterrupt to solve this and the function
takes care of all the details and avoids doing anything that isn't safe
to do inside a signal handler. The only thing we need to do is to
manually setup our own fake SIGINT handler that behaves the same way as
the standalone Python REPL signal handler (which raises a
KeyboardInterrupt).

>From what I understand the old code used to work with Python 2 so I kept
the old code around until we officially drop support for Python 2.

There is a small gap here with Python 3.0->3.1 where we might still be
crashing, but those versions have reached their EOL more than a decade
ago so I think we don't need to bother about them.

Differential revision: https://reviews.llvm.org/D104886