Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32.4k
Description
Bug report
Bug description:
Since#118579 (introduced in 3.13),Bdb.set_trace will callBdb.set_stepinstr instead ofBdb.set_step (on L406):
Lines 389 to 407 in6d3b520
| defset_trace(self,frame=None): | |
| """Start debugging from frame. | |
| If frame is not specified, debugging starts from caller's frame. | |
| """ | |
| sys.settrace(None) | |
| ifframeisNone: | |
| frame=sys._getframe().f_back | |
| self.reset() | |
| self.enterframe=frame | |
| whileframe: | |
| frame.f_trace=self.trace_dispatch | |
| self.botframe=frame | |
| self.frame_trace_lines_opcodes[frame]= (frame.f_trace_lines,frame.f_trace_opcodes) | |
| # We need f_trace_lines == True for the debugger to work | |
| frame.f_trace_lines=True | |
| frame=frame.f_back | |
| self.set_stepinstr() | |
| sys.settrace(self.trace_dispatch) |
This ends up settingf_trace_opcodes to True on all the frames of the stack.
This is fine for most use cases, but for some reason, this removes thef_lineno attribute of frames in exotic setups usingbreakpoint():
any(some_condforelinit)andbreakpoint()# -> Warning: lineno is None[1,2]andbreakpoint()# -> Warning: lineno is NoneTrueandbreakpoint()# Fine, lineno available
I'm using these inline conditions a lot to conditionally add a breakpoint, and not having access to the line number is annoying as many commands (such aslist) will fail because they expectframe.f_lineno tonot beNone (and thus crashes and exits the debugger).
I'm not familiar with opcodes and how this interacts with frames. It is expected for thef_lineno to be lost here?
CPython versions tested on:
3.13, 3.14
Operating systems tested on:
Linux