Navigation

    Fuze Arena Logo
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Popular
    • Users
    • Groups
    • Help
    • Discord

    Stack overflow with =Controls(n)

    Bug Reporting (FUZE 4 Nintendo Switch)
    7
    10
    1145
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      doumdoum F last edited by

      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
                                                                      
      
      1 Reply Last reply Reply Quote 4
      • Discostew
        Discostew F last edited by

        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?

        1 Reply Last reply Reply Quote 0
        • pico8-jihem
          pico8-jihem F last edited by 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.

          D 1 Reply Last reply Reply Quote 2
          • D
            doumdoum F @pico8-jihem last edited by doumdoum

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

            1 Reply Last reply Reply Quote 0
            • Martin
              Martin Fuze Team last edited by

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

              1 Reply Last reply Reply Quote 0
              • V
                void00 F last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • Zero Division
                  Zero Division last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • I
                    IANRASE last edited by pianofire

                    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.

                    I 1 Reply Last reply Reply Quote 1
                    • I
                      IANRASE @IANRASE last edited by

                      This post is deleted!
                      1 Reply Last reply Reply Quote 0
                      • Martin
                        Martin Fuze Team last edited by

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

                        1 Reply Last reply Reply Quote 2
                        • First post
                          Last post