End of weird behaviour - no more stack overflow
Erlend
Posts: 612
This has been one of those (many) times when I have a feeling the bug is dead simple, but I keep commenting out code, adding debug readouts, etc. etc. until I note that behaviour is really strange, it's not merely crashing. So, I am thinking somewhere in my code I am writing to an illeagal address, and I go through all of the LONG[]:= etc, but the strangeness continues.
I spend hours.
I know I cannot stop until I have solved it.
After commenting out all code, and uncommenting back small bits at the time, I learn that even defining and assigning variables makes the application go haywire.
Then 'eureka': the stack is too small!
64 was ok when the code was at the skeleton stage, but it is has been growing, and I have forgotten.
Tried 128 - still strange behaviour, then 256, and now things are strange no more, but behaving as I intended.
I need a break.
But how can I determine the sufficient size of a stack? Is it by guesstimate and trial&error?
Erlend
I spend hours.
I know I cannot stop until I have solved it.
After commenting out all code, and uncommenting back small bits at the time, I learn that even defining and assigning variables makes the application go haywire.
Then 'eureka': the stack is too small!
64 was ok when the code was at the skeleton stage, but it is has been growing, and I have forgotten.
Tried 128 - still strange behaviour, then 256, and now things are strange no more, but behaving as I intended.
I need a break.
But how can I determine the sufficient size of a stack? Is it by guesstimate and trial&error?
Erlend
Comments
Another way to estimate the amount of stack space needed is to look at the call graph of your program (what methods call what other methods) and attach an estimate of the stack size needed for each call (not including other methods called). You can then recursively traverse the graph, either by hand or with a program, to find the path through the graph that uses the most stack space and that's the most that you'll need (plus some "fudge" factor). The hard part is estimating the amount of stack space needed for expressions, especially when the expressions involve method calls.
I've done this by hand a couple of times. It's tedious and I usually just use a large fudge factor for expressions. For FemtoBasic this was important since the stack space is shared with the Basic program and there's recursion involved. I had to come up with a reasonable estimate for the stack space used for each recursion.
The best way to do the above is to have the compiler do it. Spin doesn't, but the GCC compilers probably do it internally as part of their optimizing process.
In general a compiler cannot know how much stack your program needs at run time.
Perhaps you have nested functions, perhaps hundreds of levels deep. How can the compiler know that at run time calls will happen that get you to the bottom of the nest?
Perhaps you have recursive functions, in which case all bets are off as to how much stack you might need.
As a first approximation you are going to need one LONG for the return address of every function you call, and nested function call, and nested... Then you need one LONG for every parameter of every function call along the way. Then you need one LONG for every local variable of every function call along the way.
With that in mind and knowing what calls what in your program you have an estimate of the stack space required.
Double that for safety.
I have never felt the need for stack checking tools. When things start behaving weirdly lack of stack is the first suspect. Crank up the stack size and try again.
-and I'd like to try out the stack-size utility at Obex, at http://obex.parallax.com/object/574 (what happened to the HTML-buttons?)
Erlend