Skip to content

Commit 5c96e71

Browse files
authored
[lldb] Don't rely on ScriptInterpreterPythonImpl::Initialize in the unit tests (#82096)
The unit tests only test the Python objects and don't actually use anything from the LLDB module. That means that all the additional complexity in ScriptInterpreterPythonImpl::Initialize is overkill. By doing the initialization by hand, we avoid the annoying ModuleNotFoundError. Traceback (most recent call last): File "<string>", line 1, in <module> ModuleNotFoundError: No module named 'lldb' The error is the result of us stubbing out the SWIG (specifically `PyInit__lldb`) because we cannot link against libLLDB from the unit tests. The downside of doing the initialization manually is that we do lose a bit of test coverage. For example, issue #70453 also manifested itself in the unit tests.
1 parent 4206d06 commit 5c96e71

File tree

1 file changed

+5
-21
lines changed

1 file changed

+5
-21
lines changed

lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp

Lines changed: 5 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -9,43 +9,27 @@
99
#include "gtest/gtest.h"
1010

1111
#include "Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h"
12-
#include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h"
13-
#include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h"
1412
#include "Plugins/ScriptInterpreter/Python/lldb-python.h"
1513

16-
#include "lldb/Host/FileSystem.h"
17-
#include "lldb/Host/HostInfo.h"
18-
1914
#include "PythonTestSuite.h"
2015
#include <optional>
2116

22-
using namespace lldb_private;
23-
class TestScriptInterpreterPython : public ScriptInterpreterPythonImpl {
24-
public:
25-
using ScriptInterpreterPythonImpl::Initialize;
26-
};
27-
2817
void PythonTestSuite::SetUp() {
29-
FileSystem::Initialize();
30-
HostInfoBase::Initialize();
31-
// ScriptInterpreterPython::Initialize() depends on HostInfo being
32-
// initializedso it can compute the python directory etc.
33-
TestScriptInterpreterPython::Initialize();
34-
3518
// Although we don't care about concurrency for the purposes of running
3619
// this test suite, Python requires the GIL to be locked even for
3720
// deallocating memory, which can happen when you call Py_DECREF or
3821
// Py_INCREF. So acquire the GIL for the entire duration of this
3922
// test suite.
23+
Py_InitializeEx(0);
4024
m_gil_state = PyGILState_Ensure();
25+
PyRun_SimpleString("import sys");
4126
}
4227

4328
void PythonTestSuite::TearDown() {
4429
PyGILState_Release(m_gil_state);
4530

46-
TestScriptInterpreterPython::Terminate();
47-
HostInfoBase::Terminate();
48-
FileSystem::Terminate();
31+
// We could call Py_FinalizeEx here, but initializing and finalizing Python is
32+
// pretty slow, so just keep Python initialized across tests.
4933
}
5034

5135
// The following functions are the Pythonic implementations of the required
@@ -219,7 +203,7 @@ bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
219203
}
220204

221205
bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
222-
PyObject *implementor, lldb::DebuggerSP debugger,
206+
PyObject *implementor, lldb::DebuggerSP debugger,
223207
StructuredDataImpl &args_impl,
224208
lldb_private::CommandReturnObject &cmd_retobj,
225209
lldb::ExecutionContextRefSP exe_ctx_ref_sp) {

0 commit comments

Comments
 (0)