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