Title: pdb go stack up/down
Type: behavior Stage: patch review
Components: Library (Lib) Versions: Python 3.10, Python 3.9, Python 3.8
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Markus.Pröller, asvetlov, blueyed, eric.araujo, georg.brandl, iritkatriel, meador.inge, ncoghlan, xdegaye
Priority: normal Keywords: patch

Created on 2010-08-18 12:17 by Markus.Pröller, last changed 2020-10-22 22:46 by iritkatriel.

File name Uploaded Description Edit
issue9633.patch meador.inge, 2010-09-02 03:10 py3k patch review
Pull Requests
URL Status Linked Edit
PR 11041 scotchka, 2018-12-10 11:25
Messages (7)
msg114213 - (view) Author: Markus Pröller (Markus.Pröller) Date: 2010-08-18 12:17

with python 2.7 I encounter the following problem:
I have created the following sample script:

import pdb

def function_1(number):
    stack_1 = number
def function_2(number):
    stack_2 = number + 1
def function_3(number):
    stack_3 = number + 1
    print stack_3

This is what I have done in the pdb session:
> c:\
-> print stack_3
(Pdb) l
  9         function_3(stack_2)
 11     def function_3(number):
 12         stack_3 = number + 1
 13         pdb.set_trace()
 14  ->     print stack_3
 16     function_1(1) [EOF]
(Pdb) stack_3
(Pdb) !stack_3 = 177
(Pdb) !print stack_3
(Pdb) u
> c:\
-> function_3(stack_2)
(Pdb) l
  4         stack_1 = number
  5         function_2(stack_1)
  7     def function_2(number):
  8         stack_2 = number + 1
  9  ->     function_3(stack_2)
 11     def function_3(number):
 12         stack_3 = number + 1
 13         pdb.set_trace()
 14         print stack_3
(Pdb) !print stack_2
(Pdb) !stack_2 = 144
(Pdb) !print stack_2
(Pdb) d
> c:\
-> print stack_3
(Pdb) l
  9         function_3(stack_2)
 11     def function_3(number):
 12         stack_3 = number + 1
 13         pdb.set_trace()
 14  ->     print stack_3
 16     function_1(1) [EOF]
(Pdb) stack_3
(Pdb) u
> c:\
-> function_3(stack_2)
(Pdb) !print stack_2

I walked through the stack and changed the values of the variables stack_x but the values weren't saved when I moved one frame up/down
msg114218 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-08-18 13:48
Thank you for the report. I don’t know pdb much, but I assume you have checked the doc to make sure this is indeed a bug. Can you test it with 3.1 and 3.2 too?

Bug tracker tip: You can find if a core developer is interested in a module in Misc/maintainers.rst and make them nosy (or assign to them, if there is a star near their name, like in Georg’s case).
msg114231 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-08-18 15:19
The problem here is that changes in the locals are only saved back to the frame when leaving the trace function, and up/down don't do that.

This could be fixed by making Pdb.curframe_locals a dictionary for all visited frames while interaction is running.  I'll look into it for 3.2.
msg115358 - (view) Author: Meador Inge (meador.inge) * (Python committer) Date: 2010-09-02 03:10
I believe this is slightly tricky because 'bdb.format_stack_entry' makes references to '.f_locals' and 'bdb.format_stack_entry' is invoked in several places in 'pdb'.  One option would be to add a extra parameter to 'bdb.format_stack_entry' to accept a dictionary of locals to operate with.

I implemented this approach and added a doctest to verify.  See attached patch.  I didn't update the 'bdb' documentation to note the new parameter, but will if this approach seems reasonable.
msg176270 - (view) Author: Xavier de Gaye (xdegaye) * (Python triager) Date: 2012-11-24 10:33
It is not only the up and down commands; the where, longlist and
source commands may also overwrite changes made to f_locals.

In Markus sample script above, and with the patch applied, when the
change made to stack_2 is followed by a step command, stack_2 value
goes back to '2' again. This is because the self.curframe_locals list
is built from scratch again when processing the new trace function
triggered after the step command and a new call to frame_getlocals
(and thus to PyFrame_FastToLocals) is made on the frame of function_2
to populate self.curframe_locals, overwritting the previous value
'144' of stack_2.

With a dictionary mapping frames to f_locals (and only updating this
dictionary when adding entries for frames that do not exist in the
dictionary), the above problem is fixed. However, running step
repeatedly until returning to function_2, causes the value of stack_2
to become '2' again when in function_2. This is because, just after
returning from the frame of function_3, the following calls are made
in call_trampoline to invoke the first (after tracing function_3)
trace function in function_2 frame; the 'frame' argument of
PyFrame_FastToLocals is the frame of function_2 and so, the call to
PyFrame_FastToLocals overwrites the value '144' of stack_2, and the
value of stack_2 is back to '2' again:

  result = PyEval_CallObject(callback, args);
  PyFrame_LocalsToFast(frame, 1);

Only the f_locals of the top level frame is saved by
PyFrame_LocalsToFast after exiting the trace function, so it is not
possible to keep consistent the changes made in the f_locals of the
lower level frames.

Another solution would be to ensure that changes made to locals at the
top level frame are not overwritten, and to explicitly make readonly
the locals of the other frames.  See how this is done at
msg304391 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2017-10-14 09:52
Note that we're currently looking into this as something that could be potentially addressed by PEP 558 and any related changes to the way that function locals interact with trace hooks:
msg379375 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2020-10-22 22:46
I've reproduced the bug on 3.10.
Date User Action Args
2020-10-22 22:46:16iritkatrielsetnosy: + iritkatriel

messages: + msg379375
versions: + Python 3.8, Python 3.9, Python 3.10, - Python 3.2
2019-04-24 02:45:55blueyedsetnosy: + blueyed
2018-12-10 11:25:36scotchkasetstage: patch review
pull_requests: + pull_request10309
2017-10-14 09:52:54ncoghlansetmessages: + msg304391
2017-10-14 07:51:52ncoghlansetnosy: + ncoghlan
2013-03-28 10:03:19georg.brandlsetassignee: georg.brandl ->
2012-12-05 11:09:20asvetlovsetnosy: + asvetlov
2012-11-24 10:33:30xdegayesetnosy: + xdegaye
messages: + msg176270
2010-09-02 03:10:33meador.ingesetkeywords: + patch
files: + issue9633.patch
messages: + msg115358
2010-08-30 13:44:42meador.ingesetnosy: + meador.inge
2010-08-18 15:19:45georg.brandlsetmessages: + msg114231
versions: + Python 3.2, - Python 2.7
2010-08-18 13:48:19eric.araujosetassignee: georg.brandl

messages: + msg114218
nosy: + georg.brandl, eric.araujo
2010-08-18 12:17:16Markus.Pröllercreate