Skip to content

incorrect line numbers in backtrace after removing a trace function #61479

Closed
Closed
incorrect line numbers in backtrace after removing a trace function#61479
Labels
interpreter-core(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or error

Description

@xdegaye
xdegaye
mannequin
opened on Feb 22, 2013
BPO 17277
Nosy @jcea, @atsuoishimoto, @abalkin, @xdegaye, @phmc
Files
  • tracer.py
  • generator.py
  • backtrace_lno.patch
  • traced_frame.patch
  • lineno_getter.patch
    		•

    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:

    assignee = None
closed_at = None
created_at = <Date 2013-02-22.16:42:49.093>
labels = ['interpreter-core', 'type-bug']
title = 'incorrect line numbers in backtrace after removing a trace function'
updated_at = <Date 2017-12-20.08:56:12.397>
user = 'https://github.com/xdegaye'

    bugs.python.org fields:

    activity = <Date 2017-12-20.08:56:12.397>
actor = 'ishimoto'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2013-02-22.16:42:49.093>
creator = 'xdegaye'
dependencies = []
files = ['29162', '29163', '29170', '29222', '35915']
hgrepos = []
issue_num = 17277
keywords = ['patch']
message_count = 8.0
messages = ['182672', '182710', '182746', '182867', '182879', '182955', '222620', '246274']
nosy_count = 6.0
nosy_names = ['jcea', 'ishimoto', 'belopolsky', 'nikratio', 'xdegaye', 'pconnell']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue17277'
versions = ['Python 2.7', 'Python 3.3', 'Python 3.4']

    Activity

    1. xdegaye commented on Feb 22, 2013

      @xdegaye
      xdegayemannequin
      on Feb 22, 2013
      MannequinAuthor

      It seems that using f_trace in the f_lineno getter PyFrame_GetLineNumber(), as
      the condition to decide when tracing is active, is incorrect.
      See the following two examples.

      In the backtrace printed by tracer.py running with python 3.3,
      the last entry should be line 12 instead of line 10:

      $ python3 /tmp/tracer.py
Traceback (most recent call last):
  File "/tmp/tracer.py", line 15, in <module>
    foo()
  File "/tmp/tracer.py", line 10, in foo
    bar()
ZeroDivisionError: division by zero

      This simple case does not occur with pdb, because pdb takes care of deleting
      the f_trace attribute of all the frames in the call stack when removing the
      trace function (see set_continue() in bdb.py). But this is not good enough when
      a generator is involved as can be seen when running generator.py. In the
      backtrace the last entry should be line 6 instead of line 8:

      $ python3 /tmp/generator.py
> /tmp/generator.py(16)<module>()
-> foo()
(Pdb) step
--Call--
> /tmp/generator.py(10)foo()
-> def foo():
(Pdb) step
> /tmp/generator.py(11)foo()
-> it = gen()
(Pdb) step
> /tmp/generator.py(12)foo()
-> next(it)
(Pdb) step
--Call--
> /tmp/generator.py(3)gen()
-> def gen():
(Pdb) return
--Return--
> /tmp/generator.py(8)gen()->0
-> yield i
(Pdb) step
> /tmp/generator.py(13)foo()
-> next(it)
(Pdb) continue
Traceback (most recent call last):
  File "/tmp/generator.py", line 16, in <module>
    foo()
  File "/tmp/generator.py", line 13, in foo
    next(it)
  File "/tmp/generator.py", line 8, in gen
    yield i
ZeroDivisionError: division by zero

      It seems that it could be possible to fix this issue by replacing the test for
      f->f_trace in PyFrame_GetLineNumber, by a test for f->f_tstate->use_tracing,
      and updating accordingly the f_lineno and f_trace setters.

    2. xdegaye
      added
      interpreter-core(Objects, Python, Grammar, and Parser dirs)
      type-bugAn unexpected behavior, bug, or error
      on Feb 22, 2013

    3. jcea commented on Feb 23, 2013

      @jcea
      jcea
      on Feb 23, 2013
      Member

      Xavier, could you possibly provide a patch and a test?

    4. xdegaye commented on Feb 23, 2013

      @xdegaye
      xdegayemannequin
      on Feb 23, 2013
      MannequinAuthor

      The patch (on the default branch) reverts one of the changes made in r72488 to
      introduce the new PyFrame_GetLineNumber() function (bpo-5954): tb_lineno is
      now back again the result of the call to PyCode_Addr2Line() instead of the
      call to PyFrame_GetLineNumber().

      The other changes made by r72488 in _warnings.c and ceval.c should also
      probably be reverted as well.

      The patch updates bdb set_continue() for consistency.

      The patch adds a test to test_sys_settrace.

    5. xdegaye commented on Feb 24, 2013

      @xdegaye
      xdegayemannequin
      on Feb 24, 2013
      MannequinAuthor

      The proposed patch fixes the backtrace line numbers issue, but it does not fix
      PyFrame_GetLineNumber() which is the recommended way to get the frame line
      number.

      As mentionned in the original message, testing for f->f_trace to implement the
      f_lineno getter is not correct. The f_lineno setter is also wrong in allowing to
      modify f_lineno when the frame is not the one that is being traced (pdb prevents
      that to happen though, in do_jump()).

      I am working on another patch that should fix the issue by changing
      PyFrame_GetLineNumber() and the f_lineno accessors.

    6. xdegaye commented on Feb 24, 2013

      @xdegaye
      xdegayemannequin
      on Feb 24, 2013
      MannequinAuthor

      fix the issue by changing PyFrame_GetLineNumber() and the f_lineno accessors

      The new patch named traced_frame.patch has been uploaded.

      Also, now it is not allowed anymore to set the f_lineno attribute of a frame
      that is not the frame being traced, as f_lasti is invalidated anyway on
      returning to the evaluation of that frame.

    7. xdegaye commented on Feb 25, 2013

      @xdegaye
      xdegayemannequin
      on Feb 25, 2013
      MannequinAuthor

      The traced_frame.patch fixes also bpo-7238 and bpo-16482.

    8. xdegaye commented on Jul 9, 2014

      @xdegaye
      xdegayemannequin
      on Jul 9, 2014
      MannequinAuthor

      The previous patch changed a field in the PyThreadState structure. This new patch is simpler and does not prevent to change f_lineno when it is not the attribute of the frame being traced. The new patch fixes also bpo-7238, bpo-16482 and bpo-17697.

    9. xdegaye commented on Jul 4, 2015

      @xdegaye
      xdegayemannequin
      on Jul 4, 2015
      MannequinAuthor

      The patch is wrong, the frame may not be run by the current PyThreadState.

    10. ezio-melotti
      transferred this issue fromon Apr 10, 2022

    11. gaogaotiantian commented on Oct 9, 2023

      @gaogaotiantian
      gaogaotiantian
      on Oct 9, 2023
      Member

      This seems to be already fixed. I can't reproduce with 3.13. Close for done.

    12. gaogaotiantian
      closed this as completedon Oct 9, 2023
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      interpreter-core(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or error

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions