This is an archive of the discontinued LLVM Phabricator instance.

[lldb/python] Fix dangling Event and CommandReturnObject references
ClosedPublic

Authored by labath on Dec 22 2021, 5:16 AM.

Details

Summary

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.

Diff Detail

Event Timeline

labath requested review of this revision.Dec 22 2021, 5:16 AM
labath created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptDec 22 2021, 5:16 AM
mib accepted this revision.Dec 23 2021, 4:10 PM

This patch looks good to me, however, may be it would be good to have a IsInitialized/ IsCleared method for all SB-types to make sure the object hasn't been cleared after going out-of-scope ?

I'm suggesting this because not all SB-types have a IsValid method and for those who have it, the implementation varies a lot from class to class. So comparing the SB object against its default constructed value could be a way to check if the object was well-formed.

Having the object reseted by SWIG if it goes out-of-scope could collide with this approach. What do you think ?

This revision is now accepted and ready to land.Dec 23 2021, 4:10 PM

This isn't a feature I would want advertise too broadly, or add special APIs to support it. The way I see it, if a user needs to check if an object has been cleared, something has gone wrong already. So I'd rather do something to discourage this use case instead of providing more support for it. Crashing is definitely discouraging, but maybe a bit too extreme. If there was a simple way to throw an exception in this case, then I think that would be a good compromise.

The reason I started looking into all of this is because of a bug report where the user wanted to stash a debugger object and access it later (which is a semi-reasonable thing to do, I'd say). I haven't heard of anybody trying to store SBCommandReturnObjects, nor I intend to start encouraging that. The only reason I wrote this patch is to tie up loose ends.

Having the object reseted by SWIG if it goes out-of-scope could collide with this approach. What do you think ?

I'm not sure what you meant by that, but I don't consider this behavior as set in stone. If we come up with a different/better way to handle this, then we can just change this code.

mib added a comment.Jan 4 2022, 12:13 AM

This isn't a feature I would want advertise too broadly, or add special APIs to support it. The way I see it, if a user needs to check if an object has been cleared, something has gone wrong already. So I'd rather do something to discourage this use case instead of providing more support for it. Crashing is definitely discouraging, but maybe a bit too extreme. If there was a simple way to throw an exception in this case, then I think that would be a good compromise.

The reason I started looking into all of this is because of a bug report where the user wanted to stash a debugger object and access it later (which is a semi-reasonable thing to do, I'd say). I haven't heard of anybody trying to store SBCommandReturnObjects, nor I intend to start encouraging that. The only reason I wrote this patch is to tie up loose ends.

Having the object reseted by SWIG if it goes out-of-scope could collide with this approach. What do you think ?

I'm not sure what you meant by that, but I don't consider this behavior as set in stone. If we come up with a different/better way to handle this, then we can just change this code.

Sounds good ! I don't have any other objection with this patch then.