[all-commits] [llvm/llvm-project] 7c8ae6: [lldb/test] Make it possible to run the mock gdb s...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7c8ae65f2c3d5c1a6aba2f7ee7588f9f76f94f84
      https://github.com/llvm/llvm-project/commit/7c8ae65f2c3d5c1a6aba2f7ee7588f9f76f94f84
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2021-11-22 (Mon, 22 Nov 2021)

  Changed paths:
    M lldb/packages/Python/lldbsuite/test/gdbclientutils.py
    M lldb/packages/Python/lldbsuite/test/lldbgdbclient.py

  Log Message:
  -----------
  [lldb/test] Make it possible to run the mock gdb server on a single thread

This is a preparatory commit to enable mocking of qemu startup. That
will involve running the mock server in a separate process, so there's
no need for multithreading.

Initialization is moved from the start function into the constructor
(which can then take an actual socket instead of a class), and the run
method is made public.

Depends on D114156.

Differential Revision: https://reviews.llvm.org/D114157


  Commit: 7f09ab08de5ae8f8bd77f5c02c70b991277eb1ae
      https://github.com/llvm/llvm-project/commit/7f09ab08de5ae8f8bd77f5c02c70b991277eb1ae
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2021-11-22 (Mon, 22 Nov 2021)

  Changed paths:
    M lldb/bindings/python/python-swigsafecast.swig
    M lldb/bindings/python/python-wrapper.swig
    M lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
    M lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp

  Log Message:
  -----------
  [lldb] Fix [some] leaks in python bindings

Using an lldb_private object in the bindings involves three steps
- wrapping the object in it's lldb::SB variant
- using swig to convert/wrap that to a PyObject
- wrapping *that* in a lldb_private::python::PythonObject

Our SBTypeToSWIGWrapper was only handling the middle part. This doesn't
just result in increased boilerplate in the callers, but is also a
functionality problem, as it's very hard to get the lifetime of of all
of these objects right. Most of the callers are creating the SB object
(step 1) on the stack, which means that we end up with dangling python
objects after the function terminates. Most of the time this isn't a
problem, because the python code does not need to persist the objects.
However, there are legitimate cases where they can do it (and even if
the use case is not completely legitimate, crashing is not the best
response to that).

For this reason, some of our code creates the SB object on the heap, but
it has another problem -- it never gets cleaned up.

This patch begins to add a new function (ToSWIGWrapper), which does all
of the three steps, while properly taking care of ownership. In the
first step, I have converted most of the leaky code (except for
SBStructuredData, which needs a bit more work).

Differential Revision: https://reviews.llvm.org/D114259


Compare: https://github.com/llvm/llvm-project/compare/247a1a55eb6a...7f09ab08de5a