Xavier de Gaye added the comment: 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: PyFrame_FastToLocals(frame); 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 http://code.google.com/p/pdb-clone/source/detail?r=5643890608fce2eac318de61f1d6d065d5a7d538 ---------- nosy: +xdegaye _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9633> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com