pdb raises BdbQuit on 'quit' when started with set_trace

[xdegaye]

BPO	16446
Nosy	@giampaolo, @asvetlov, @xdegaye
Files	issue16446.patch quit.py branch-27.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2012-11-08.23:09:53.394>
labels = ['type-bug', 'library']
title = "pdb raises BdbQuit on 'quit' when started with set_trace"
updated_at = <Date 2014-07-19.21:24:34.417>
user = 'https://github.com/xdegaye'

bugs.python.org fields:

activity = <Date 2014-07-19.21:24:34.417>
actor = 'terry.reedy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2012-11-08.23:09:53.394>
creator = 'xdegaye'
dependencies = []
files = ['29208', '29231', '29232']
hgrepos = []
issue_num = 16446
keywords = ['patch']
message_count = 8.0
messages = ['175205', '176275', '182596', '182821', '182932', '182933', '219213', '219230']
nosy_count = 5.0
nosy_names = ['giampaolo.rodola', 'asvetlov', 'xdegaye', 'nailor', 'rmarko']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue16446'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']

[xdegaye]

Also, the two oldest frames of the stack are identical (sic),
according to the printed traceback.

$ python3 foo.py
> /tmp/foo.py(3)<module>()
-> x = 1
(Pdb) import sys; print(sys.version)
3.2.2 (default, Dec 27 2011, 17:35:55) 
[GCC 4.3.2]
(Pdb) list
  1     import pdb
  2     pdb.set_trace()
  3  -> x = 1
  4
[EOF]
(Pdb) quit
Traceback (most recent call last):
  File "foo.py", line 3, in <module>
    x = 1
  File "foo.py", line 3, in <module>
    x = 1
  File "/usr/local/lib/python3.2/bdb.py", line 46, in trace_dispatch
    return self.dispatch_line(frame)
  File "/usr/local/lib/python3.2/bdb.py", line 65, in dispatch_line
    if self.quitting: raise BdbQuit
bdb.BdbQuit
$

[xdegaye]

See how this is fixed at
http://code.google.com/p/pdb-clone/source/detail?r=8bbac1ffee749fcfd96ea3a2aaca1f240cafc2cc

[giampaolo]

I also bumped into this problem on both 2.7 and 3.3. It is very annoying.

[nailor]

I took Xavier's patch and ported in on the 2.7. It'll probably go as is for 3.2.

The functionality seems to be working and tests pass.

[xdegaye]

There is an error in my patch (already fixed in pdb-clone) and in Jyrki's patch.
Running Jyrki's patch on quit.py produces the following output where the line
number in the last entry of the backtrace is incorrect (should be line 9 instead
of line 7):

$ python quit.py
--Return--
> /tmp/quit.py(4)bar()->None
-> pdb.Pdb().set_trace()
(Pdb) quit
Traceback (most recent call last):
  File "quit.py", line 11, in <module>
    foo()
  File "quit.py", line 7, in foo
    bar()
ZeroDivisionError: integer division or modulo by zero

This problem does not occur when bpo-17277 is fixed.
Meanwhile the attached patch, based on Jyrki's patch and based on the 2.7
branch, fixes this.

[xdegaye]

The patch changes the semantics of the quit command: quit behaves like the gdb
detach command when pdb is started with set_trace.

[rmarko]

Would be nice to have this commited as without this change

-        if self.quitting:
-            return # None
+        if not self.botframe:
+            self.botframe = frame

it's not possible to quit Bdb (and the code it's executing) as it just returns and doesn't raise BdbQuit.

[xdegaye]

Yes the patch does change the semantics of the quit command:

* no change when pdb is run as a script or with 'python -m pdb script_name'. As stated in the doc, the 'quit command': "Quit from the debugger. The program being executed is aborted."

* but when a set_trace() breakpoint is inserted, 'quit' just terminates the debugger and the program continues its execution. It is the purpose of the patch to prevent an inconvenient crash with BdbQuit in that case. The idea is that the hard-coded breakpoint was set to investigate a local problem and one may want to let it run afterwards (for example to check its behavior after having changed some its internal state with pdb).

Sorry, I should have documented that behavior change.

[gaogaotiantian]

I don't think currently we are planning to change the semantics of quit - continue is doing exactly that. Close as not planned, feel free to discuss more if anyone has different opinions.