OpenEuphoria

trace(1) bug

• Posted by CChris <christian.cuvier at agriculture.?ouv.?r> Nov 13, 2007
• 576 views

Using Eu 3.1 official:

with trace
trace(1)
for i=1 to 3 do
?i
end for
for i=1 to 2 do
?i
end for
integer i i=5
?0

Step into program until in second loop. The current value of i is displayed
correctly.
Then enter "?i": the correct value is erased, and "i=3" is incorrectly
displayed, at a different screen location.
Keep stepping forward to the second last statement, and enter "?i" again. You'll
get "i=3" displayed, instead of the expected "not defined at this point" message.
This will happen whether you performed the first "?i" or not.
Press enter to last stateùment and do "?i" again. You'll get "i=3" instead of
"i=5".

Reason: the logic of RTLookup() in be_symtab.c wrongly assumes that it should
return the first maching top level loop index, while several with the same name
are likely to be defined. And it has no idea whether an SC_GLOOP_VAR var is in
scope at the current trace location, or that a local var may override loop
indexes.

Tentative fix: 
1/ keep track of the last matching variable in file instead of returning on
first found. When <var>stop</var> is reached, if any was found, then return it.
2/ to fix the middle problem ("i=3" instead of "not defined"), the ENDFOR_*
opcodes should set the loop var to NOVALUE, which never happens during its
observable life span. The "not defined" message could be displayed then for loop
indexes, and "<no value>" for other vars that just didn't get a value yet.
3/ apply same strategy for private symbols, but you can return when a SC_PRIVATE
is found. Otherwise return last defined index instead of first.

I don't have a C compiler at work; I'll try to submit a tested fix ASAP.

CChris