[issue17697] Incorrect stacktrace from pdb
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17697 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17697] Incorrect stacktrace from pdb
Xavier de Gaye added the comment: The call to set_trace() installs a local trace function on all the frames of the stack, including on the oldest frame, i.e. the module level frame. This causes the invocation of frame_settrace() in frameobject.c and the module frame f_lineno is evaluated by PyCode_Addr2Line() (this happens only on the first call to set_trace() since the module frame local trace is never removed). Next, the 'continue' command sets the global trace function to None and removes the local trace function of all the frames of the stack, *except* the module frame (see set_continue() in bdb.py). On printing the stack with the 'where' command, the bdb get_stack() function invokes frame_getlineno() that calls PyFrame_GetLineNumber() that assumes that the module frame f_lineno is correct since it has a local trace function. But as the global trace function has been set to None by the 'continue' command, f_lineno is not updated by the interpreter tracing code when running the module level frame. Hence the problem. The root cause is that PyFrame_GetLineNumber assumes incorrectly that when a frame has a local trace function, its f_lineno is correct. Issue 7238 and issue 17277 are also related to this issue. -- nosy: +xdegaye ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17697 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17697] Incorrect stacktrace from pdb
New submission from Don Allen: Give the attached file execute permission and run it. At the first breakpoint, the backtrace will be correct. Continue. At the second breakpoint, a backtrace will show the foo('first call') on the stack when, in fact, the call came from foo('second call'), as verified by the printed message. I am running this on an up-to-date 64-bit Arch Linux system. Python 3.3.1. -- components: Library (Lib) files: python_bug.py messages: 186561 nosy: donaldcallen priority: normal severity: normal status: open title: Incorrect stacktrace from pdb type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file29777/python_bug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17697 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17697] Incorrect stacktrace from pdb
Ian Kelly added the comment: The bug also occurs using 32-bit Python 3.3.1 on Windows 7. -- nosy: +ikelly ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17697 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17697] Incorrect stacktrace from pdb
Ned Deily added the comment: On python-list, Robert Kern used where to demonstrate the problem: $ python pdbbug.py first call --Return-- /Users/rkern/scratch/pdbbug.py(4)foo()-None - pdb.set_trace() (Pdb) where /Users/rkern/scratch/pdbbug.py(5)module() - foo('first call') /Users/rkern/scratch/pdbbug.py(4)foo()-None - pdb.set_trace() (Pdb) c second call --Return-- /Users/rkern/scratch/pdbbug.py(4)foo()-None - pdb.set_trace() (Pdb) where /Users/rkern/scratch/pdbbug.py(5)module() - foo('first call') /Users/rkern/scratch/pdbbug.py(4)foo()-None - pdb.set_trace() (Pdb) Searching other open pdb issues, applying the suggested fix from Issue16482 seems to correct the problem here. -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17697 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17697] Incorrect stacktrace from pdb
Changes by Ned Deily n...@acm.org: -- stage: - needs patch versions: +Python 2.7, Python 3.2, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17697 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com