OpenEuphoria

Re: trace(1) bug

• Posted by Robert Craig <rds at Rapid?upho?ia.com> Nov 13, 2007
• 570 views

CChris wrote:
> Using Eu 3.1 official:
> }}}
<eucode>
> 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
> </eucode>
{{{

> 
> 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.

I'd be delighted if you can fix this.
Someone recently sent me a big complicated example
that seems to show the very same problem. It looked 
rather difficult to diagnose and fix, so I was tempted 
to lazily post it to the SourceForge bug tracker and forget
about it for a while. 

Now that Euphoria is an open source project,
people should post all bug reports to EUforum and/or 
the SourceForge bug tracker.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com