Clearing the Stack?

CannibalRobotics

So I've got this huge program that runs great for a matter of several hours across 7 cogs. It uses allot of recursion and infinite loops in three of the cogs. The others are running FullDuplexSerial and the Floating point routines.
At some point, variables in the Top object (and possibly others) start getting set to the wrong value and it slowly degrades from there. If I let it run long enough, occasionally it will start getting the right answers again. Other times it will keep running but the calculations are just wrong.
Interestingly enough, I can identify the source of the wrong values. They start coming from variables 4 or 5 long's away from where they are supposed to be in the VAR section.
I have tried all sorts of stack allocations across all of the cogs, trying to minimize and maximize, nothing seems to help.
I've tried some of the code suggestions regarding measuring stack depth but when I write all of the 'same character' into the stack location of one cog, the whole program locks up.
My experience tells me I'm missing something obvious but I've just looked at it too long.
Short of building in hourly resets - is there any way to get control of this?

mindrobots

On a humorous note, I imagine a similar conversation going on in conference room in Redmond, WA several years ago. "It seems to run for a while but every so often, you just need to reboot the computer and start off fresh...." Thus, the final Beta of Windows 3.0 is ready for general release.

Is some data walking on top of something else? Functionally, your code seems to work but time (memory leaks) or data (something not big enough) throws your program into fits. Something defined incorrectly, buffer too small, time sensitive...good until 9:59 but at 10:00 it goes bad?

Without specifics of the program, it's going to be pretty hard to help out more than with just generic thoughts.

Rick.

Mike Green

Infinite loops are not, by themselves, going to use much stack space. The recursive routines could potentially use a lot and be hard to predict. If there are only a few places where recursion takes place, you could put in a check for stack space used. Other options could be to reduce or eliminate the use of recursion by changing algorithms or by modifying the algorithm to use an explicit data stack in the program rather than the implicit subroutine call stack.

To get the stack pointer, you could reference @RESULT or, if there are local variables, get the address of the last local variable.

CannibalRobotics

That's it! I'll just call it a "feature" - I'll make BILLions.
Thought about posting the code but it's massive.
I can't really nail down a time or an event. I'm wondering if the recursive nature of it is continually grabbing more memory and it eventually eats into the variable area?

Dave Hein

CannibalRobotics wrote: »

I've tried some of the code suggestions regarding measuring stack depth but when I write all of the 'same character' into the stack location of one cog, the whole program locks up.

A cog should not run differently if it's stack is initialized with the same character. You may be using an unitialized stack variable. Try pre-setting the stack to zero, and then try pre-setting to some other value. If it works in one case, but not the other your code is depending on a previous state of a stack variable before it sets it.

Dave

CannibalRobotics

Dave Hein wrote: »

You may be using an unitialized stack variable.

If I'm only calling them by their name and not their address, how could I do this?

Dave Hein

The following example uses an unitialized variable.

pub StringSize(str) | size
  repeat while byte[str++]
    size++
  return size

It assumes size is initialized to zero, which is not a valid assumption.

CannibalRobotics

OK,
No that's not it, I was thinking in terms of the address not the value.
Any Value is initialized before I use it.

RS_Jim

Can you compile your program with different objects not running? This might be a clue as to which obj is causing the problem.
Jim