Xavier de Gaye <xdeg...@gmail.com> added the comment:
> Perhaps we should should test whether the exception happened there and not
> drop in the debugger in that case?
The same kind of problem occurs for any post-mortem debugging raised by an
uncaught exception in the user code: the backtrace displayed by the 'bt'
command shows frames that are owned by the pdb and bdb modules; and worse, the
'up' command allows to move to these frames. See for example below what happens
when debugging foo.py that contains only the line "1/0". IMO this problem
should be handled in another issue and in that case, in your example, 'bt'
output would be empty.
$ python -m pdb foo.py
> /tmp/foo.py(1)<module>()
-> 1/0
(Pdb) c
Traceback (most recent call last):
File "/usr/lib/python3.8/pdb.py", line 1703, in main
pdb._runscript(mainpyfile)
File "/usr/lib/python3.8/pdb.py", line 1572, in _runscript
self.run(statement)
File "/usr/lib/python3.8/bdb.py", line 580, in run
exec(cmd, globals, locals)
File "<string>", line 1, in <module>
File "/tmp/foo.py", line 1, in <module>
1/0
ZeroDivisionError: division by zero
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> /tmp/foo.py(1)<module>()
-> 1/0
(Pdb) bt
/usr/lib/python3.8/pdb.py(1703)main()
-> pdb._runscript(mainpyfile)
/usr/lib/python3.8/pdb.py(1572)_runscript()
-> self.run(statement)
/usr/lib/python3.8/bdb.py(580)run()
-> exec(cmd, globals, locals)
<string>(1)<module>()
> /tmp/foo.py(1)<module>()
-> 1/0
(Pdb)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue40403>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
