lldb does not trigger confirm prompt onCtrl+D, only on commands.gdb triggers on all. I prefer consistency sopdb will trigger confirmation in all cases.
We don't want to make the quitting process too cumbersome for users, so there are more than one way to confirm:
- y/Y as suggested in the prompt
- <enter> so you can doq,<enter>,<enter>
- Ctrl+D so you can doCtrl+D,Ctrl+D
The latter two are not listed in the prompt because the prompt would be a bit confusing. That's howgdb andlldb does it as well. (they do have slightly different policies on some input).
n/N will return to debugger, all other inputs brings you back to the prompt
os._exit(0) vssys.exit(0). I gave some thoughts about how we should exit, do we want to do it gracefully. I chose theos._exit(0) at the end because I think when the users attach a debugger and want to quit, they don't care about whether the process will end gracefully (with all the atexit callbacks and potential exit routines), they just want to stop the process. If they want the process to run to the end, they should doc instead ofq.
In rare cases, where a separate non-daemon thread is there or the code in a raw try ... except ... block, force exit would do well for a debugger.

Issue:Do not raise an Exception when exiting pdb #124703

gaogaotiantian added2 commits

September 27, 2024 11:30

Do not raise an Exception for exit in inline mode anymore

8ad5baa

Use lower + strip

63a6bf6

gaogaotiantian requested a review fromiritkatriel

September 27, 2024 19:20

bedevere-appbot added the awaiting core review label

Sep 27, 2024

bedevere-appbot mentioned this pull request

Sep 27, 2024

Do not raise an Exception when exiting pdb#124703

Closed

📜🤖 Added by blurb_it.

5747b27

JelleZijlstra reviewed

Sep 29, 2024

View reviewed changes

Lib/pdb.py Outdated

		reply = 'y'
		self.message('')
		if reply == 'y' or reply == '':
		os._exit(0)

Copy link

Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I think I'd prefersys.exit here.os._exit may lead to unreleased resources. If the user wants to kill the process faster, they can hit Ctrl-C or Ctrl-\ after.

Copy link

MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

It's always possible to have unreleased resources - we can't prevent that withSystemExit. It may get better in some cases, but raisingSystemExit in an arbitrary place of the code does not seem like a very safe way to end the program to me. The only way to make sure all resources are released (if the program is written correctly) is tocontinue the program.

One of the problem ofSystemExit is:

whileTrue:try:breakpoint()except:pass

This will trap in debugger forever. I know this example is a bit artificial, but it's not that rare for programs to handleSystemExit, and it's frustrating for users to be stuck in the debugger when they just want to quit.

We have a warning for the users already and they should be aware that they are "killing" a process - which means the resources could potentially be leaked. At least they'll know the process will definitely be killed after they say yes.

Of course that's my thought, and is open to more discussion.

Copy link

MemberAuthor

gaogaotiantian commentedOct 8, 2024

I'm having second thought about this. Not because of the resource release, but it seems like some people will bring up pdb in REPL, for example by running some code withbreakpoint() in it. Force quit will kill REPL as well. So maybeSystemExit would be a better choice and it kind of provides a similar backwards compatibility toBdbQuit.