Xavier de Gaye added the comment:
I can reproduce the problem on python 3.5 with test3.py as:
def foo():
foo = 7789
bar = 7788
$ python
Python 3.5.0a4+ (default:8bac00eadfda, May 6 2015, 17:40:12)
[GCC 4.9.2 20150304 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pdb, test3
>>> pdb.run('test3.foo()')
> <string>(1)<module>()
(Pdb) step
--Call--
> /home/xavier/tmp/test3.py(1)foo()
-> def foo():
(Pdb) break 3
Breakpoint 1 at /home/xavier/tmp/test3.py:3
(Pdb) continue
> /home/xavier/tmp/test3.py(3)foo()
-> bar = 7788
(Pdb) continue
>>> pdb.run('test3.foo()')
> <string>(1)<module>()
(Pdb) step
--Call--
> /home/xavier/tmp/test3.py(1)foo()
-> def foo():
(Pdb) break # 'break' lists no breakpoints.
(Pdb) break 2
Breakpoint 2 at /home/xavier/tmp/test3.py:2
(Pdb) break # 'break' lists two breakpoints.
Num Type Disp Enb Where
1 breakpoint keep yes at /home/xavier/tmp/test3.py:3
breakpoint already hit 1 time
2 breakpoint keep yes at /home/xavier/tmp/test3.py:2
(Pdb)
On the second debugging session, the first 'break' command lists no
breakpoints, while the second 'break' command lists two breakpoints including
the one set in the first debugging session.
The problem is that the 'breaks' attribute of the Pdb instance is inconsistent
with the 'bplist' and 'bpbynumber' class attributes of the bdb.Breakpoint
class when the second debugging session is started.
----------
nosy: +xdegaye
versions: +Python 3.5
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24160>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
