Incorrect stacktrace from pdb #61897

Activity

1. donaldcallen commented on Apr 11, 2013

   

   donaldcallenmannequin

   on Apr 11, 2013

   MannequinAuthor

   More actions

   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.
2. donaldcallen

   added

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Apr 11, 2013
3. ikelly commented on Apr 11, 2013

   

   ikellymannequin

   on Apr 11, 2013

   Mannequin

   More actions

   The bug also occurs using 32-bit Python 3.3.1 on Windows 7.
4. ned-deily commented on Apr 11, 2013

   

   ned-deily

   on Apr 11, 2013

   Member

   More actions

   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 bpo-16482 seems to correct the problem here.
5. xdegaye commented on Apr 12, 2013

   

   xdegayemannequin

   on Apr 12, 2013

   Mannequin

   More actions

   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.

   bpo-7238 and bpo-17277 are also related to this issue.
6. ezio-melotti

   transferred this issue fromon Apr 10, 2022
7. gaogaotiantian commented on Oct 9, 2023

   

   gaogaotiantian

   on Oct 9, 2023

   Member

   More actions

   This is already fixed somewhere along the way. Not reproducible in Python 3.13. Close for done.
8. gaogaotiantian

   closed this as completedon Oct 9, 2023