Bug report
Bug description:
Since #118579 (introduced in 3.13), Bdb.set_trace will call Bdb.set_stepinstr instead of Bdb.set_step (on L406):
| def set_trace(self, frame=None): | |
| """Start debugging from frame. | |
| If frame is not specified, debugging starts from caller's frame. | |
| """ | |
| sys.settrace(None) | |
| if frame is None: | |
| frame = sys._getframe().f_back | |
| self.reset() | |
| self.enterframe = frame | |
| while frame: | |
| 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 setting f_trace_opcodes to True on all the frames of the stack.
This is fine for most use cases, but for some reason, this removes the f_lineno attribute of frames in exotic setups using breakpoint():
any(some_cond for el in it) and breakpoint() # -> Warning: lineno is None [1, 2] and breakpoint() # -> Warning: lineno is None True and breakpoint() # 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 as list) will fail because they expect frame.f_lineno to not be None (and thus crashes and exits the debugger).
I'm not familiar with opcodes and how this interacts with frames. It is expected for the f_lineno to be lost here?
CPython versions tested on:
3.13, 3.14
Operating systems tested on:
Linux