[BUG] App Crash Due to Nested Variable Self-Reference

[Jeff]

Code: Select all

[MeasureHours]
Measure=Calc
Formula=#Minutes# / 60
DynamicVariables=1
[MeterHours]
Meter=String
MeasureName=MeasureHours
FontSize=100
FontColor=FFFFFF
SolidColor=00000001
NumOfDecimals=1
LeftMouseUpAction=[!SetVariable "Minutes" "([#Minutes] + 1)"]

This is the entire skin and I have a very strange feeling of deja-vu.
Basically, I remember reading a part about how Variables can be created dynamically and how they don't need to exist in the skin at all, however, if you have those variable names already in the file, and they are uninitialized/inexistent, but you create them, when Rainmeter gose through the Update cycle, it crashes.
This happens ONLY when the variable is NEVER initialized, it can easily be circumvented by just adding it to [Variables], but the bug pertains to it crashing if the section is never written or when the variable gets spawned out of thin air.

[Yincognito]

Code: Select all

[MeasureHours]
Measure=Calc
Formula=#Minutes# / 60
DynamicVariables=1
[MeterHours]
Meter=String
MeasureName=MeasureHours
FontSize=100
FontColor=FFFFFF
SolidColor=00000001
NumOfDecimals=1
LeftMouseUpAction=[!SetVariable "Minutes" "([#Minutes] + 1)"]

This is the entire skin and I have a very strange feeling of deja-vu.
Basically, I remember reading a part about how Variables can be created dynamically and how they don't need to exist in the skin at all, however, if you have those variable names already in the file, and they are uninitialized/inexistent, but you create them, when Rainmeter gose through the Update cycle, it crashes.
This happens ONLY when the variable is NEVER initialized, it can easily be circumvented by just adding it to [Variables], but the bug pertains to it crashing if the section is never written or when the variable gets spawned out of thin air.

Yep, it happens for me too - and it probably shouldn't, but not necessarily because of what you're thinking (at least that's my impression). Before trying to create a variable dynamically without it existing in the skin yet (which I'm sure will not cause Rainmeter to crash), you're actually referencing a variable that doesn't exist yet, in the formula. Even more so, it only happens when using the nested syntax for the variable when referencing it, it won't happen when using the classic syntax. I believe it's these two that cause Rainmneter to crash (well, technically, it hangs, but anyway), and the error appearing in the log before the hang seems to agree (just try to click this with the About > Skins window open, maybe even inserting a !Log before to see the variable's value). Or, it's about the double referencing when using the nested syntax (if my understanding of it is correct), maybe even the lost square brackets that are not replaced from the variable string.

[Brian]

Welp....you broke the nested syntax parser.

Yincognito is correct, it technically hangs...then crashes.

There are a couple of things happening here. First, while you are correct that you can create a variable dynamically, you are also assuming that the newly created variable is defaulted to "something" (presumably "0", since you are using it in a formula).

That is the first mistake. When creating the variable, you are basically setting it to itself + 1, but once that variable gets resolved, it doesn't exist yet, so it just returns the original text.

It is no different than this:

Code: Select all

[Variables]
Minutes=([#Minutes] + 1)

That also produces the same hang...then crash. What happens is [#Minutes] is replaced with ([#Minutes] + 1), then it evaluated again and again until the internal stack is too large and Rainmeter crashes.

This self-referencing is the second (unintended, obviously) mistake.

However.....

This all shouldn't hang or crash Rainmeter...and fixing it is somewhat tricky. Either we can't allow a variable to self-reference itself (with nested syntax) within the variable's value, or we may have to limit how many nested substitutions can be done on a variable before it bails out and just returns with what it has. Obviously either way needs to produce an error message.

I'll have to chew on this for bit, so stay tuned...

-Brian

[Yincognito]

This all shouldn't hang or crash Rainmeter...and fixing it is somewhat tricky. Either we can't allow a variable to self-reference itself (with nested syntax) within the variable's value, or we may have to limit how many nested substitutions can be done on a variable before it bails out and just returns with what it has. Obviously either way needs to produce an error message.

I'll have to chew on this for bit, so stay tuned...

-Brian

I just hope that the nested syntax and its clear advantages and capabilities (as well as the useful changes done to improve it over the years) won't be afected. In case it's not obvious, the hang and crash also happen when mixing with the escaped syntax, EVEN if the variable is previously defined - I'm sure there is a reason for it as well (maybe the 2nd mistake you mentioned), but just in case it helps:

Code: Select all

[Variables]
Minutes=0

[MeasureHours]
Measure=Calc
Formula=(#Minutes#/60)
DynamicVariables=1

[MeterHours]
Meter=String
MeasureName=MeasureHours
FontSize=100
FontColor=FFFFFF
SolidColor=00000001
NumOfDecimals=1
LeftMouseUpAction=[!Log "[#Minutes]"][!SetVariable Minutes ([#*Minutes*]+1)]
DynamicVariables=1

[Jeff]

Even more so, it only happens when using the nested syntax for the variable when referencing it, it won't happen when using the classic syntax. I believe it's these two that cause Rainmneter to crash (well, technically, it hangs, but anyway)

I partially decided to use Nested Variables because they are dynamically resolved when they are used, I didn't wanna use Classic Variables because I didn't wanna add DV to the meter too (since I knew that previous function Nested Variables have), I actually didn't even test classic variables, but I understand now why and why referencing with the variable existing in the [Variables] section dosen't do it

and the error appearing in the log before the hang seems to agree

Haha whoops, I didn't even check that window at all, I only checked the Skins tab to see the number go up and crash, never crossed my mind to go one page behind

---

What happens is [#Minutes] is replaced with ([#Minutes] + 1), then it evaluated again and again until the internal stack is too large and Rainmeter crashes.

This self-referencing is the second (unintended, obviously) mistake.

However.....

This all shouldn't hang or crash Rainmeter...and fixing it is somewhat tricky. Either we can't allow a variable to self-reference itself (with nested syntax) within the variable's value, or we may have to limit how many nested substitutions can be done on a variable before it bails out and just returns with what it has. Obviously either way needs to produce an error message.

I'll have to chew on this for bit, so stay tuned...

-Brian

Sorry for the long text ahead.

I'll have to be honest with this one, but this seems like an intended behavior, Rainmeter is actually doing the correct job self referencing even if it means the app crashes.
To give an example where we can extract the same behavior, in LUA the _G environment and __index metamethod are self referential, when you do for key, value in pairs(_G) do print(key) end and it references _G back, that is indeed correct and dose the job right. If after that you try to get what each key's references (so for string you try to get that it has string.sub etc.), you'll run into infinity, recursively getting where _G points (to itself).
So Rainmeter is doing the right thing, the question is if to limit the behavior to circumvent the crash in cases like this (I think Formula and Conditional Operations accept only 100 nested conditions, maybe for this behavior 3 nested is enough? but then again in other programming languages there are no rules for this, they just hang... and then crash) or to not do anything.
I personally wouldn't change anything, as the blame falls on the user for this/my error for initializing a self-referential behavior. I feel like this kind of behavior can't happen by accident (well, maybe it can if do [#Minute[#Second]] but [#Second] fails, I'd be hard pressed to find a user that could do this though) and is done only deliberately by hand.
I changed the post title to reflect the problem a bit better.

That's my rant over, as a funny little ending node, if you recursively try to get _G's values you will end up with stuff like _G._G._G._G.Measure.__index.__index.__index.__index.GetValueRange, which I find funny. For some reason getfenv(1) is also in the global list and you have 1.SELF there. LUA Code here for the thing I wrote to get that long string.

[Yincognito]

I partially decided to use Nested Variables because they are dynamically resolved when they are used, I didn't wanna use Classic Variables because I didn't wanna add DV to the meter too (since I knew that previous function Nested Variables have)

Yep, I've seen this approach in other cases too - it's easy to use the nested syntax when it has so many advantages. Personally, I use it only when actually nesting or need the immediate value in the same option, as it also serves as an indication that "somethig special" is happening there, due to the Notepad++ coloring.

Haha whoops, I didn't even check that window at all, I only checked the Skins tab to see the number go up and crash, never crossed my mind to go one page behind

Generally, using the log isn't of much help In a hang / crash scenario, but here I thought I could "steal" some info from Rainmeter before dying on me.

I personally wouldn't change anything, as the blame falls on the user for this/my error for initializing a self-referential behavior.

I kinda tend to agree with this - in a way, it's pointless to have checks on infinite loops or unorthodox self referencing. Up to Brian to decide though.

[Cariboudjan]

Love using nested variables due to them being dynamic in combination with !Delay to execute a different action within the same line if a value changes between when the line is executed vs. when the delay completes. Excellent substitute for using ActionTimer.