Stack Overflow Error with too many variables - how exactly does stack behave

In my Weathergraph watchface I often run into this error (as I seem to be pushing into many CIQ limits) - I think it has to do with too many variables declared in various scopes (global, class, method).

Failed invoking <symbol>
Stack Overflow Error

I have enough free RAM, so this seems like there is another limit (stack < free RAM), I'd like to understand how exactly stack in Monkey C works so that I can know how to work around this:

- what exactly counts as stack? global variabes? class variables? scope variables? all of them?
- what exactly is the limit? Is there a limited memory for stack? Or is that a number of entries in some variables table? Can I work around this by using eg. an array (have one larger array with all variables instead of having many separately named variables)?
- is there a known workaround for this (having lot of free ram, but running into Stack Overflow limit)?

Thanks - I searched the docs, but I believe this isn't documented anywhere.

Top Replies

FlowState over 2 years ago in reply to DaveBrillhart +1

DaveBrillhart said:
I think they could easily support 512 items. As the power and memory allowance increases, that just makes sense. Saying it worked fine in the past, so no need to expand, sounds like…

All Replies

0 Former Member over 6 years ago

Local variables will be put on the stack. (I think this is what you mean when you say "scope variables")

There is a static limit to the size of the stack, but you won't be able to track a number of stack variables because your stack is affected by more than just locals. Calling functions will push the frame pointer to the stack. Executing some op-codes will push arguments on to the stack. Recursive functions can eat up stack rapidly.

You can work around this bug by having less locals. Packing your locals into an array, dictionary or class would reduce the amount of stack you are using because the container is on the stack, and the other elements are in the container. Variables in a container will take longer to access than locals.

There is no way to increase the size of the application stack at this time.

0 DaveBrillhart over 2 years ago in reply to Former Member

Wow - just ran into this. Such a strange Stack Overflow bug. A function call worked fine usually, but in one particular code path, the same exact function call with the same values threw this error. I reduced the local variables in the calling function and now it works fine.

0 dpawlyk over 2 years ago in reply to DaveBrillhart

Keep in mind that the function call increases the stack memory (the stack includes all functions all the way up the call chain).

0 jim_m_58 over 2 years ago in reply to dpawlyk

And then there is also a limit of 8 or 9 (I forget) parameters to a function

0 dpawlyk over 2 years ago in reply to jim_m_58

That really should be a compiler error.

0 _psx_ over 2 years ago in reply to jim_m_58

0 DaveBrillhart over 2 years ago in reply to jim_m_58

And a limit of, I think, 255 globals. In my case, the issue was the # locals in the calling function. At least by changing 16 into two 8-element arrays, it eliminated the issue.

0 _psx_ over 2 years ago in reply to DaveBrillhart

there is the limit of 255 in many places (globals, locals, members, resources etc.)

0 waterkip over 2 years ago in reply to _psx_

I wonder why that is..

0 jim_m_58 over 2 years ago in reply to waterkip

references to things are stored in a byte. The max unsigned 8 bit value is 255.

255 has pretty much worked for the last 7 years ('ve never has an issue with it) and making these things 2 bytes would increase memory usage and result in issues with backwards compatibility. You'd have a whole bunch of cases where apps would no longer run on older devices.