New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pdb continue followed by an exception in the same frame shows incorrect frame linenumber #70966
Comments
Consider this simple python program - 1 #!/usr/bin/python On running this program - % ./python /tmp/test.py
Am here in func
> /tmp/test.py(16)func()
-> print ( "Am here after pdb" )
(Pdb) c
Am here after pdb
Am going to assert now
File "/tmp/test.py", line 25, in <module>
main()
File "/tmp/test.py", line 22, in main
func()
File "/tmp/test.py", line 16, in func
print ( "Am here after pdb" )
> /tmp/test.py(16)func()
-> print ( "Am here after pdb" ) >>>> This should have been at the line corresponding to "Am going to assert now"
(Pdb) This seems to be an bug ( due to a performance consideration ) with the way python bdb's set_continue() has been implemented - https://hg.python.org/cpython/file/2.7/Lib/bdb.py#l227 def set_continue(self):
# Don't stop except at breakpoints or when finished
self._set_stopinfo(self.botframe, None, -1)
if not self.breaks:
# no breakpoints; run without debugger overhead
sys.settrace(None)
frame = sys._getframe().f_back
while frame and frame is not self.botframe:
del frame.f_trace
frame = frame.f_back Basically what happens after "c" in a "(Pdb)" prompt is that bdb optimizes for the case where there are no more break points found by cleaning up the trace callback from all the frames. However, all of this happens in the context of tracing itself and hence the trace_dispatch function in https://hg.python.org/cpython/file/2.7/Lib/bdb.py#l45 still returns back the trace_dispatch as the new system trace function. For more details on sys.settrace(), check https://docs.python.org/2/library/sys.html#sys.settrace Check, the function trace_trampoline at https://hg.python.org/cpython/file/2.7/Python/sysmodule.c#l353 This seems to be an bug ( due to a performance consideration ) with the way python bdb's set_continue() has been implemented - https://hg.python.org/cpython/file/2.7/Lib/bdb.py#l227 def set_continue(self):
# Don't stop except at breakpoints or when finished
self._set_stopinfo(self.botframe, None, -1)
if not self.breaks:
# no breakpoints; run without debugger overhead
sys.settrace(None)
frame = sys._getframe().f_back
while frame and frame is not self.botframe:
del frame.f_trace
frame = frame.f_back Basically what happens after "c" in a "(Pdb)" prompt is that bdb optimizes for the case where there are no more break points found by cleaning up the trace callback from all the frames. However, all of this happens in the context of tracing itself and hence the trace_dispatch function in https://hg.python.org/cpython/file/2.7/Lib/bdb.py#l45 still returns back the trace_dispatch as the new system trace function. For more details on sys.settrace(), check https://docs.python.org/2/library/sys.html#sys.settrace Check, the function trace_trampoline at https://hg.python.org/cpython/file/2.7/Python/sysmodule.c#l353 Now, check the function PyFrame_GetLineNumber() which is used by the traceback to get the frame line number https://hg.python.org/cpython/file/2.7/Objects/frameobject.c#l63 int
PyFrame_GetLineNumber(PyFrameObject *f)
{
if (f->f_trace)
return f->f_lineno;
else
return PyCode_Addr2Line(f->f_code, f->f_lasti);
} Basically this function returns back the stored f->f_lineno in case the f->f_trace is enabled. The fix is fortunately simple - Just set self.trace_dispatch to None if pdb set_continue decides to run without debugger overhead. |
ping |
ping. Gentle reminder to review the patch |
See also bpo-24565. |
Ran into a similar issue today This issue (and mine is fixed) in python 3.10. Most probaly related to bpo-24565 fix |
I meant: this issue is fixed in 3.10 |
If this was fixed in 3.10, we can close this; 3.9 only accept security fixes now. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: