Stack overflow with =Controls(n)

doumdoum

This program ends after 2 minutes

c=Controls(0)  // << No stack overflow, without this line
Loop
    c=Controls(0)
    Update()   // << remove this line for instant stack overflow
Repeat
-----------------------------------------------------
results in stack overflow at line 3, 
too many functions called, 
maximum memory for variables exceeded.
Context 63A35000

This one works fine

ReadJoystick()
Loop
    ReadJoystick()
Repeat

Function ReadJoystick()
    c=Controls(0)
Return Void

Discostew

That is interesting.

Maybe the reason why the second example works is because you technically are going out-of-scope after the assignment of Controls when you leave the function, thereby clearing that variable. Will it cause a stack overflow is you returned the assigned variable in the function?

pico8-jihem

I have the same case. You have to create your variables outside the main loop. If not, new ones are created for each loop... I think the garbage collector should destroy all memory allocations without reference before running a new loop.

doumdoum

@pico8-jihem
c is referenced before the loop in the first example

Martin

Thank you for the report and more importantly the workaround. We are aware of this.

void00

I been having issues with it too and it seems when a variable is reassigned instead of just getting a new value .a new variable is created and the old variable remains but new variable gets the old variable address which later on there become to many variables leading to stack overflow.

Zero Division

Me too. I have a largish program and tracking it down by commenting things out is whack-a-mole.

How does the workaround work? If I move all of my in-loop assignments out to void support functions, will that avoid triggering the overflow bug?

I'd like find an idiom that works and stick with it until the patch, if I can. Otherwise I'm stuck waiting on version 0.2.11 to continue.

IANRASE

I have encountered a similar problem with pretty much any kind of loop where a lot of functions are called repeatedly.
e.g. the following results in stack overflow as well

keysPressed = ""
while len(keysPressed) == 0 loop
    keysPressed = getKeyboardBuffer()
repeat

but if you throw in something that forces the loop to take longer (like a sleep or update), it runs completely fine, e.g.

keysPressed = ""
while len(keysPressed) == 0 loop
    sleep(0.0001)
    keysPressed = getKeyboardBuffer()
repeat

will not cause any overflow or too many function calls issues.

This doesn't seem limited to input operations, I've had it do the same with loops that just print or increment a variable.

My guess is that the interpreter is simply creating and discarding the loop frames too quickly for the garbage collector to keep up.

It confused me at first because logically each loop would be added to the stack and then removed before the next loop is added - but if you consider that the interpreter is coded in a garbage collected language like Java or C#, that stack is actually a dynamically allocated object constantly causing things to be added and scheduled for removal from the heap in a very short amount of time.

It could very well be that references are properly freed in the interpreter's code before each new loop is created, but the garbage collector doesn't check often enough. The devs could request or force garbage collection after each loop, but that would significantly slow execution. I don't know what kind of GC is working behind the scenes, or how much control the devs have over it, but assuming this is the case, the problem could be solved just by decreasing the collection threshold or increase frequency of checks just enough to prevent it from happening. Assuming references only exist within either global scope or immediate scope and are destroyed when leaving those scopes, allocation would ideally be static with no need for GC, but that might not be possible depending on what F4NS is built on (e.g. in C#, some libraries don't play nice when you alter memory management or use unsafe code like stackalloc, and you don't always have the necessary permissions for fine control in Java depending on the platform and JVM settings).

Anyway that's all assuming the F4NS code interpreter is done in a garbage collected OO language with the usual garbage collection set up. Assuming it's done in C#, I know from experience that fine tuning garbage collection can be a lot of work, especially if that wasn't an initial design consideration, as C# is largely geared toward not having to worry about allocation or garbage collection, and a lot is left to the runtime implementation.

Or it could be something simple like recursive loop interpretation or some other memory leak somewhere else.

Anyway, that's all just a lot of speculation on my part, the short answer is, if your loops are causing memory issues, move variable creation/initialization outside of the loop when possible and if it's still an issue try slowing it down by calling update() if appropriate or sleeping for some small fraction of a second.

IANRASE

This post is deleted!

Martin

Please wait for the next patch before worrying too much about any of this