[lldb/python] Fix dangling Event and CommandReturnObject references

Unlike the rest of our SB objects, SBEvent and SBCommandReturnObject
have the ability to hold non-owning pointers to their non-SB

[lldb/python] Fix dangling Event and CommandReturnObject references

Unlike the rest of our SB objects, SBEvent and SBCommandReturnObject
have the ability to hold non-owning pointers to their non-SB
counterparts. This makes it hard to ensure the SB objects do not become
dangling once their backing object goes away.

While we could make these two objects behave like others, that would
require plubming even more shared pointers through our internal code
(Event objects are mostly prepared for it, CommandReturnObject are not).
Doing so seems unnecessarily disruptive, given that (unlike for some of
the other objects) I don't see any good reason why would someone want to
hold onto these objects after the function terminates.

For that reason, this patch implements a different approach -- the SB
objects will still hold non-owning pointers, but they will be reset to
the empty/default state as soon as the function terminates. This python
code will not crash if the user decides to store these objects -- but
the objects themselves will be useless/empty.

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

show more ...

[lldb/python] Avoid more dangling pointers in python glue code

[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 aw

[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

show more ...

[lldb/python] Plug SBStructuredData leaks

This applies the from D114259 to the SBStructuredData class.

[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 PyO

[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

show more ...

[lldb] Deobfuscate python-swigsafecast.swig

This file was way more complicated than it needed to be.

This patch removes the automagic reference-to-pointer delegation and
replaces the template speci

[lldb] Deobfuscate python-swigsafecast.swig

This file was way more complicated than it needed to be.

This patch removes the automagic reference-to-pointer delegation and
replaces the template specializations with regular free functions
(taking reference arguments).

The reason I chose references is twofold:
- there are more arguments being passed by reference than by pointer
- the reference arguments make it more obvious that there is a lot of
leaking going on in there.

Currently, the code was assuming that the pointer arguments have some
kind of a special meaning and that pointer functions take ownership of
their arguments, which isn't true (it's possible it was true at some
point in the past, I haven't done the archeology).

This makes it easier to implement proper lifetime management in
follow-up patches.

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

show more ...

Revert "Revert "Add the ability to write target stop-hooks using the ScriptInterpreter.""

This reverts commit f775fe59640a2e837ad059a8f40e26989d4f9831.

I fixed a return type error in the original p

Revert "Revert "Add the ability to write target stop-hooks using the ScriptInterpreter.""

This reverts commit f775fe59640a2e837ad059a8f40e26989d4f9831.

I fixed a return type error in the original patch that was causing a test failure.
Also added a REQUIRES: python to the shell test so we'll skip this for
people who build lldb w/o Python.
Also added another test for the error printing.

show more ...

Revert "Add the ability to write target stop-hooks using the ScriptInterpreter."

This temporarily reverts commit b65966cff65bfb66de59621347ffd97238d3f645
while Jim figures out why the test is failin

Revert "Add the ability to write target stop-hooks using the ScriptInterpreter."

This temporarily reverts commit b65966cff65bfb66de59621347ffd97238d3f645
while Jim figures out why the test is failing on the bots.

show more ...

Add the ability to write target stop-hooks using the ScriptInterpreter.

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

[lldb/Bindings] Move bindings into their own subdirectory

All the code required to generate the language bindings for Python and
Lua lives under scripts, even though the majority of this code aren't

[lldb/Bindings] Move bindings into their own subdirectory

All the code required to generate the language bindings for Python and
Lua lives under scripts, even though the majority of this code aren't
scripts at all, and surrounded by scripts that are totally unrelated.

I've reorganized these files and moved everything related to the
language bindings into a new top-level directory named bindings. This
makes the corresponding files self contained and much more discoverable.

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

show more ...