[all-commits] [llvm/llvm-project] 7406d2: [lldb/python] Fix (some) dangling pointers in our ...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7406d236d873d74b01c3cef285e5d9012dcef151
      https://github.com/llvm/llvm-project/commit/7406d236d873d74b01c3cef285e5d9012dcef151
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2021-12-20 (Mon, 20 Dec 2021)

  Changed paths:
    M lldb/bindings/python/python-swigsafecast.swig
    M lldb/bindings/python/python-wrapper.swig
    M lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h
    M lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
    M lldb/test/API/commands/command/script/TestCommandScript.py
    A lldb/test/API/commands/command/script/persistence.py
    M lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp

  Log Message:
  -----------
  [lldb/python] Fix (some) dangling pointers in our glue code

This starts to fix the other half of the lifetime problems in this code
-- dangling references. SB objects created on the stack will go away
when the function returns, which is a problem if the python code they
were meant for stashes a reference to them somewhere.  Most of the time
this goes by unnoticed, as the code rarely has a reason to store these,
but in case it does, we shouldn't respond by crashing.

This patch fixes the management for a couple of SB objects (Debugger,
Frame, Thread). The SB objects are now created on the heap, and
their ownership is immediately passed on to SWIG, which will ensure they
are destroyed when the last python reference goes away. I will handle
the other objects in separate patches.

I include one test which demonstrates the lifetime issue for SBDebugger.
Strictly speaking, one should create a test case for each of these
objects and each of the contexts they are being used. That would require
figuring out how to persist (and later access) each of these objects.
Some of those may involve a lot of hoop-jumping (we can run python code
from within a frame-format string). I don't think that is
necessary/worth it since the new wrapper functions make it very hard to
get this wrong.

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