classification
Title: change value of local variable in debug
Type: behavior Stage:
Components: Versions: Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Markus.Pröller, amaury.forgeotdarc, benjamin.peterson, georg.brandl, maru, mproeller
Priority: normal Keywords: patch

Created on 2009-02-11 07:43 by mproeller, last changed 2010-08-18 11:01 by amaury.forgeotdarc. This issue is now closed.

Files
File name Uploaded Description Edit
pdb_cache_f_locals.patch maru, 2009-04-01 22:49 Patch to cache f_locals during traceback
pdb.py Markus.Pröller, 2010-08-18 06:17
Messages (11)
msg81631 - (view) Author: (mproeller) Date: 2009-02-11 07:43
The following code produces problems:

import pdb
def func():
	b = 13
	pdb.set_trace()
	a = b + 2
	print a
func()

If I change the value of b (e.g. to 3) everything works fine
(print a => displays 5)
but if I want to change b (e.g. to 3) and display the value,
it is reset to 13
(and print a displays 15)
msg81664 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-02-11 20:24
Could you describe the problem in more detail please? I've having
trouble understanding you description. For example, you could you paste
the pdb session you used and explain what you expected?
msg81733 - (view) Author: (mproeller) Date: 2009-02-12 08:33
This is the pdb session at the tracepoint in line 4 in the function func
()
So I did the following first:

> c:\test.py(5)func()
-> a = b + 2
(Pdb) p b
13
(Pdb) !b=5
(Pdb) p b
13
(Pdb) n
> c:\test.py(6)func()
-> print a
(Pdb) n
15

I tried to change the value of b but it didn't work, as the
print a statement printed 15, but it should have printed 7
because I set b to 5!!
Then I did the same again:

> c:\test.py(5)func()
-> a = b + 2
(Pdb) p b
13
(Pdb) !b = 5
(Pdb) n
> c:\test.py(6)func()
-> print a
(Pdb) n
7

Note that I changed the value of b to 5 and than didn't print the value
of b and it seems to work as the print statement printed 7.
msg85105 - (view) Author: Maru Newby (maru) * Date: 2009-04-01 22:49
Modifications to the f_locals dict are only saved at the end of
traceback, and each traceback function was using the f_locals accessor
that returns the dict state as of the start of traceback.  The provided
patch caches f_locals on setup and ensures that all traceback functions
share that cached dict, ensuring that modifications are no longer
overwritten by a function using the unmodified dict.
msg85209 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-04-02 15:09
Committed in r71006.
msg114102 - (view) Author: Markus Pröller (Markus.Pröller) Date: 2010-08-17 07:35
Hello,

I have tested this patch since a while. In the meantime I have switched to Python 2.6.5, but the problem that I described above is still there.

Another problem that brought the patch is, that when I move a frame up in the stack trace, the variables of the current stack are not available any more (only the variables of the newest frame are available).
msg114103 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-08-17 08:01
> In the meantime I have switched to Python 2.6.5,
> but the problem that I described above is still there.
The fix was made for 2.7, and not backported to 2.6.

> Another problem that brought the patch is, that when I move a frame up
> in the stack trace, the variables of the current stack are not available
> any more (only the variables of the newest frame are available).
This is not my experience: the variables of the current frame are available. What did you do exactly?
msg114200 - (view) Author: Markus Pröller (Markus.Pröller) Date: 2010-08-18 06:17
Hello,

I changed pdb.py to the file I added in the attachment (I just used the given patch pdb_cache_f_locals.patch)

Then I created the following file:

import pdb

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

and run that file with python -i <filename>
This is my python version:
---------------------------------------
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
-----------------------------------------
And here is what I did in the pdb session:
> c:\tst_pdb.py(14)function_3()
-> print stack_3
(Pdb) !print stack_3
3
(Pdb) u
> c:\tst_pdb.py(9)function_2()
-> function_3(stack_2)
(Pdb) l
  4         stack_1 = number
  5         function_2(stack_1)
  6
  7     def function_2(number):
  8         stack_2 = number + 1
  9  ->     function_3(stack_2)
 10
 11     def function_3(number):
 12         stack_3 = number + 1
 13         pdb.set_trace()
 14         print stack_3
(Pdb) !print stack_2
*** NameError: name 'stack_2' is not defined
(Pdb) d
> c:\tst_pdb.py(14)function_3()
-> print stack_3
(Pdb) l
  9         function_3(stack_2)
 10
 11     def function_3(number):
 12         stack_3 = number + 1
 13         pdb.set_trace()
 14  ->     print stack_3
 15
 16     function_1(1) [EOF]
(Pdb) !stack_3 = 125 #this works now with the patch
(Pdb) !print stack_3
125
(Pdb)

When I use my original pdb.py, I can print variable stack_2 when I move one frame up, but can't change the value of these local variables.
msg114201 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-08-18 06:29
Ah, the patch is buggy; it was corrected with r71019 which indeed fixes "up" and "down". You could try to apply this change to your local copy.

Also consider upgrading to 2.7, where everything works as expected...
msg114206 - (view) Author: Markus Pröller (Markus.Pröller) Date: 2010-08-18 09:05
Okay,

thanks for giving me the correct patch, but I still face the following problem (with the same code snippet):

> c:\tst_pdb.py(14)function_3()
-> print stack_3
(Pdb) l
  9         function_3(stack_2)
 10
 11     def function_3(number):
 12         stack_3 = number + 1
 13         pdb.set_trace()
 14  ->     print stack_3
 15
 16     function_1(1) [EOF]
(Pdb) stack_3
3
(Pdb) !stack_3 = 177
(Pdb) !print stack_3
177
(Pdb) u
> c:\tst_pdb.py(9)function_2()
-> function_3(stack_2)
(Pdb) l
  4         stack_1 = number
  5         function_2(stack_1)
  6
  7     def function_2(number):
  8         stack_2 = number + 1
  9  ->     function_3(stack_2)
 10
 11     def function_3(number):
 12         stack_3 = number + 1
 13         pdb.set_trace()
 14         print stack_3
(Pdb) !print stack_2
2
(Pdb) !stack_2 = 144
(Pdb) !print stack_2
144
(Pdb) d
> c:\tst_pdb.py(14)function_3()
-> print stack_3
(Pdb) l
  9         function_3(stack_2)
 10
 11     def function_3(number):
 12         stack_3 = number + 1
 13         pdb.set_trace()
 14  ->     print stack_3
 15
 16     function_1(1) [EOF]
(Pdb) stack_3
3
(Pdb) u
> c:\tst_pdb.py(9)function_2()
-> function_3(stack_2)
(Pdb) !print stack_2
2
(Pdb)

I set the value of stack_3 to 177, go one frame up, do something, go one frame down and stack_3 is 3 again (not 177 as expected)
msg114209 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-08-18 11:01
Right, this last problem still exists with 2.7 or 3.1. Please open a new tracker item for it, and let's close this one.
History
Date User Action Args
2010-08-18 11:01:03amaury.forgeotdarcsetmessages: + msg114209
2010-08-18 09:05:39Markus.Pröllersetmessages: + msg114206
2010-08-18 06:29:10amaury.forgeotdarcsetmessages: + msg114201
2010-08-18 06:18:05Markus.Pröllersetfiles: + pdb.py

messages: + msg114200
2010-08-17 08:01:24amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg114103
2010-08-17 07:35:18Markus.Pröllersetversions: + Python 2.6, - Python 2.5
nosy: + Markus.Pröller

messages: + msg114102

components: - None
2009-04-02 15:09:07georg.brandlsetstatus: open -> closed

nosy: + georg.brandl
messages: + msg85209

resolution: fixed
2009-04-01 22:49:27marusetfiles: + pdb_cache_f_locals.patch

nosy: + maru
messages: + msg85105

keywords: + patch
2009-02-12 08:33:29mproellersetmessages: + msg81733
2009-02-11 20:24:16benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg81664
2009-02-11 07:43:01mproellercreate