Explicitly close the remote session

[liona24]

Description/Motivation/Screenshots

This solves an issue with the __del__ magic method being called unreliably, in particular it will often get called just when creating a new remote session using gef-remote which causes an exception in the __del__ hook:

<method 'disconnect' of 'gdb.EventRegistry' objects> returned a result with an exception set

Because of this exception gdb has to be restarted before using the gef-remote command again.

Against which architecture was this tested ?

"Tested" indicates that the PR works and the unit test (i.e. make test) run passes without issue.

• x86-32
• x86-64
• ARM
• AARCH64
• MIPS
• POWERPC
• SPARC
• RISC-V

Checklist

• My PR was done against the dev branch, not main.
• My code follows the code style of this project.
• My change includes a change to the documentation, if required.
• If my change adds new code, adequate tests have been added.
• I have read and agree to the CONTRIBUTING document.

[hugsy]

I don't see any issue with merging this PR, but can you provide an example of how to trigger the issue you experienced in a first place?

[liona24]

Consider something like this:

gef> gef-remote 10.10.10.10 1234
...
gef> detach
gef> gef-remote 10.10.10.10 1234
Error: <method 'disconnect' of 'gdb.EventRegistry' objects> returned a result with an exception set

The second gef-remote will always fail until one restarts gdb. (GNU gdb (GDB) Fedora 12.1-1.fc36)

[hugsy]

If that's the only case, it's possible we miss to catch that type of events. I'll investigate further later.

[liona24]

There does not seem to be another event for that. The exit_handler is definitely invoked, the __del__ invocation is just deferred for some reason. Maybe it's a GC thing, I am not sure ..

[hugsy]

I found yesterday there is a new type of event called events.connection_removed but it seems to be there only for gdb11+. So your solution may be a good universal workaround.

[liona24]

Well the exit_handler is definitely invoked anyway so I am not sure if we really need that event. I also tried if forcing gc.collect() would help, but that does not seem to be the case. I cannot think of any other solution than explicitly cleaning up.
Btw, can you reproduce this? Ubuntu 22.04 in docker also seems to have this issue for me.

[Grazfather]

__del__ isn't guaranteed to be called when you run del. It'll only be called when the garbage collector runs. This is better.

[Grazfather]

this comment doesn't make sense actually

[Grazfather]

del is a keyword not a function, let's fix it.

[hugsy]

@Grazfather The gc runs every time a refcount hits 0 which will be the case here. In any case it's out of the topic of this PR.
@liona24 I tried to find if existing events would help us but couldn't find any. So let's go with your PR 😀 With the small you gave me here can you write a small regression test? Nothing fancy, just to be sure we keep an eye on it

[Grazfather]

No, the GC runs when it runs. If the refcount hits 0 that just means the GC will take care of it. Using del on the last ref doesn't guarantee it'll be immediately cleaned up.

[liona24]

I added a simple regression test and applied the other suggestions