Unable to (always) call `.do_longlist()` from SIGINT handler

[goodboy]

Something I've again noticed only in 3.10 (i think?).

Synopsis

in tractor as part of goodboy/tractor#165 we have a custom pdbpp.Pdb and a new WIP custom SIGINT handler which is designed to more or less prevent clobbering of the pdbpp REPL when in use by a child process. The idea is there is a global process tree lock that prevents more then one in-tree sub-process from using the root's TTY at once. This normally works well (except for a couple edge cases that are being ironed out / deferred).

tractor is built on trio and requires special management of the stdlib's pdb flags in order to avoid breaking structured-concurrency style KBI handling:

• Stack spew when quitting via the debugger python-trio/trio#1155
• Stack spew when quitting via the debugger python-trio/trio#1155 (comment)
• as an example we also override the breakpoint() builtin to address this

Intended UX

When inside the pdp repl we want to shield off SIGINT to avoid it causing downstream cancellation in (nested) child subprocs which is one of the main reasons for the custom handler and instance flag adjustments:

• .nosigint = True which tells the pdbp instance not to override with it's own SIGINT handler and,
• .allow_kbint = True which is to tell the custom handler to always raise KBI if it did get called. ).

The desired behavior is to simply have a log message tell the user that some actor is currently in debug so SIGINT is being ignored until the debugger is released (by sending continue or quit) and in this case we simply want to .do_longlist() at the last frame to avoid seeing only that log msg and instead put the user "back to where they were" console-ux wise.

Current issue

It seems that when sending next commands during a "pdp instance session" (where we are interacting and waiting on either of continue or quit to be issued) it can go into some sort of weird state where the .curframe is not set on the instance:

(Pdb++)
pdbpp longlist failed...
Traceback (most recent call last):
  File "/home/goodboy/repos/tractor/tractor/_debug.py", line 714, in shield_sigint
    pdb_obj.do_longlist(None)
  File "/home/goodboy/repos/pdbpp/src/pdbpp.py", line 1180, in do_longlist
    self._printlonglist(max_lines=False)
  File "/home/goodboy/repos/pdbpp/src/pdbpp.py", line 1186, in _printlonglist
    if self.curframe.f_code.co_name == '<module>':
AttributeError: 'MultiActorPdb' object has no attribute 'curframe'
--KeyboardInterrupt--
(Pdb++)

Digging into this I found that self.curframe seems to be first set inside the stdlib's code: Pdp.setup() which leads me to believe somehow the instance can get to a place where it's been created but .setup() hasn't yet been called?

I'm not entirely sure where to start to meta-debug this issue 😂 and would love to know if just trying to call longlist from a handler is totally not recommended and if there is some alternative / better way to accomplish this desired UX.

look forward to your thoughts and recommendations 😎

[goodboy]

Yes, i will try to produce a test for this and #496