Local: name shadows another variable BUG!!!!

[Lagi Pittas]

Hi

This has cropped up a few times over the last few months but I usually fix it by renaming the "offending" variable.

Usually restarting livecode does not seem to work.

Today I had the error crop up - on code that worked last night and I was just debugging - I did not add any new variable.

I have strict compilation on

I have 4 smallish routines that use the same LOCAL variable lnItem, lnRowPos, lcButton

I renamed the lnItem to lnKeyNum (just in case there is some bad Hashing going on in the Core - I don't think so but Straws are pretty hard to Clutch).

It went to the next routine and said lcButton was shadowing - so I replace all in the stack. So next it went to the other routine and decided It didn't like a different Variable so I thought (OK I swore like a trooper)

I removed strict compilation on and yes it compiled. Put it back on - same thing.

So I thioght I'd do some testing before I started whining.

Code: Select all

Local lnItem, lnRowPos, lnKeyNum, lnX
Local lnMenu

If I get a shadow error with lnItem but i switch the order as so ....

Code: Select all

Local lnRowPos, lnItem,  lnKeyNum, lnX
Local lnMenu

The compilation fails at lnRowPos if I switch them back it fails on lnItem again. I also added a new variable (fred) and it still fails on the previous one it did before.

I am loath to go to non Strict compilation (Pascal does that to you) but Ive been declaring my variable with Foxpro and Clipper for the best part of 25 years

Old Habits Die Hard

Can someone please explain a foolproof way of sorting this or if you are litening O Great Ones at RunRev Towers - Sort it out please!- there is a 2013 thread with this same problem but at least exiting and starting again works - this is getting worse now. Nothing like a bug that is enhanced with time ....


How about a preferences "refresh" variables if you haven't got the time to fix "Non important Bugs"

<EndOfRant>

Regards Lagi

[dunbarx]

Just another test, if you have a script such as:

Code: Select all

on mouseup
   local lnRowPos, lnItem,  lnKeyNum, lnX
   Local lnMenu
end mouseUp

Nothing else, does the script compile?

Craig Newman

[FourthWorld]

Is it possible there's another declaration of the troublesome variables elsewhere in the script?

Can you post the script in its entirety so we might try to reproduce this?

[mwieder]

Lagi-

While I haven't seen this myself (and I *always* keep strict compilation enabled), I've seen it reported by various people sporadically over the last couple of years.
Do you also have 'variable preservation' enabled as well as strict compilation?

...and just to check, are the local variables declared within the handlers or are they common to the whole script?
...and what version of LC are you having this trouble with?

I'd love to find a completely reproducible recipe for this some day.

...one more stupid question... you don't have a dreaded global variable somewhere in some script with the same name, do you?

[phaworth]

I've suffered form this this since the day I started using strict compilation mode. In my case, restarting LC seems to fix the problem but I sometimes end up having to do that several times a day.. In some cases, all works fine over the course of several compilations and suddenly, up pops the error.

I know there are others, like Mark, who never see this problem and I wish we could somehow figure out what the environmental differences are that result in this happening for some and not for others. Is there some sort of coding style factor perhaps? I'veI have never been able to come up with a recipe to reliably reproduce it

In answer to Mark's question, yes I do have variable preservation switched on. I can't remember for sure but I think I have tried switching that off in the past and still experienced the same issue.

Like many other Livecoders, I have naming conventions for variables depending on their scope so it's highly unlikely that these errors are being caused by genuine duplication. In fact, I've run scripts to check for duplicate variable names across all loaded stacks and their controls at the time the error occurs (local/script local, local/global, script local/global) and never found any.

There are several bug reports on this and some suggested solutions but none that have worked for me. I've offered to run any customized/logging version of LC that the team could provide me with to help track this down but no response. I'm always prepared to provide a recipe or a sample stack when possible but it's just not possible for this bug. I understand the team are busy with other much more exciting stuff but at some point, I'd really like to see them take some time to track this down by the good old fashioned way of looking at the compilation code in the engine.

Pete

[mwieder]

Pete, Lagi-

Believe me, I sympathize with your pain on this.
I'd really like to blame this on a persistence error due to variable preservation because that would neatly fit a theory, but from what I've heard that doesn't seem to be a common cause (I never have variable preservation enabled, btw). Even when folks have sent me scripts that caused a problem for them I couldn't replicate it.

[phaworth]

I will try swithcing variable preservation off and see what happens. To be honest, I've never been quite sure what variable preservation does. I've assumed that if I have a script cloal variable and I make a change to a handler in the same script, it will preserve its value. If that's the case, then switching it off will be a problem for me since Ioften use script local variables that are loaded with data when a stack opens, coupled with handlers in the script that set/get its values. Preference settings, for example.

[snm]

Usually I see this error when start debugging the script and stop it before the end. Then when I change something in this script I can't save it becauee of this error.
I don't remember such error it I let script to go to the end.

Marek

[Lagi Pittas]

Hi All

Sorry for the late answer the forums where down for me all last night.

answering while still horizontal in bed .. First thing I did on waking up.

To answer some of the suggestions ...

I will probably have variable preservation on ..I'll check later
There are no rogue variables outside the handler and no global variables at all only custom properties and 1 script local multidimensional array I couldn't get to working as a custom variable.


Out of all the suggestions I think the last one from Marek seems to be the one that holds the most promise to track this down and the reason is the script compiled perfectly the night before, I then started debugging single step and stopped before the program ended mid a little 9 line routine with a repeat statement in it.


I then tried to change the variable that I was indexing the array with cnMenu instead of the variable lnRowPos and think that's when the trouble started.

I'm going to go back to the version 2 nights ago and try to debug it again and see if I can replicate it

ll check in tonight asI have a pretty busy day not at the computer

Thanks to all for suggestions in glad I'm not the only one who thinks having new additions to play is not more important than fixing old bugs. sometime instead of adding newstuff only bugs shoud be fixed for six months or at least have 1 engineer dedicated to solving the bugs that have been on the runrev ride the longest.

Kindest Regards Lagi

[Lagi Pittas]

UPPDATE
========

I got the original version of the app and cut and pasted the two handlers that I had changed - I have strict compilation on and variable preservation and the whole thing compiles without a whimper.
So it looks like the Debugger is causing the problem as Marek surmised.

Regards Lagi

[mwieder]

Lagi-

Well, that would explain why I've never seen this, since I use my own debugger.
I'll experiment a bit without it and see if I can replicate the problem.

[phaworth]

The debugger angle sounds promising. I can't be 100% sure but I think that applies to !y experience too. I'll keep track of that grom now on.
Pete

[mwieder]

IIRC the built-in debugger has a state machine that sometimes gets into trouble.
It's entirely possible that stopping it mid-stream ends up in a partially-running state and confuses the engine.
This is definitely a promising line of thought.

[phaworth]

I've been careful to note if I stopped debug early before the error occurs and so far, that has been the case every time. So at least for me, that is the cause of the problem. I'm still faced with quitting and restring LC when it does happen (or switch off Strict Compilation Mode), so I'm training myself to not stop debug runs early.
Pete

[mwieder]

The debugger uses three interactive system properties to control the state machine:

the traceStack
the traceReturn
the traceAbort

If you're in the middle of debugging something, the traceStack will have the name of the stack being worked on. Otherwise it will be empty.
The traceAbort will be false if the debugger is still active; setting it true will in most cases end the debugging session.
The traceReturn will normally be true; if you see it false the state machine is in an intermediate state.

So instead of quitting and restarting, you might try examining these properties and adjusting them to see if that helps get you out of trouble.