Tracking down stack-heap collisions

I don't suppose there's a handy debug tool or anything for figuring out how/why a stack-collision is occuring?

I have a VERY complicated script, however most of the time it does very little (it just sits and respawns the buttons needed for its operation).

Anyway, I've studied the functions that this thing is calling and I'm not getting anywhere! The only explaination I could think of is a list or string that just keeps on getting bigger and bigger, but there is no such string or list, as the running parts of the script shouldn't be touching any lists except for tiny little temporary ones. Same for strings, the only global variables this alters are a couple of integers and a key.

It basically works like:

Create buttons, store the key given to them and tell them who we are (and how long to 'live' for).
Wait for the x seconds that the buttons are expected to live for.
Re-create buttons and repeat.

This calls a few things, but nothing obviously at fault:

createButtons() - if there is on id then create the buttons, steps including creating a listen (storing the channel and ID of the listen in global variables that are re-used). It then messages the new buttons with the parent's ID and the time the buttons should wait before deleting.
object_rez() - takes the key of the new buttons and stores it, creates a listen to receive messages from it (done this way to avoid the unlikely event of two copies spawning buttons with the same channel and conflicting). Begin the count-down to respawn.
timer() - if time is up for the button then create a new set essentially repeating.

setTimer() - a special function which looks at all the possible timed events and see if any should trigger sooner. e.g if there is another rezzed object that will be deleted before the buttons, then we will want to deal with it first, so set the timer to that time.


This is really confusing me, as I've even gone and confirmed exactly which path in each function is being called, but I can't figure out how anything could be over-flowing! The only strings/lists that are manipulated are temporary, none of the global variables are being touched (otherwise normal functioning of the item would be screwed up completely). As it is I leave it, with it happily functioning, respawning its buttons as expected, but when I come back on the buttons aren't there and the script has to be reset manually.

Any hints/tips on what to look for? I have the feeling I'm probably looking in the right places already and coming up dry, but re-hashing them can't hurt, there be some that I've missed.

I would be sure to check that you are not appending to a list each time without resetting it to an empty list i.e. [] first.

Check for any place where you're appending to a list. So:

list foo;

...

foo += [...];

// or

foo = foo + [...];

If you have code like that, and you don't have code that resets the list to an empty list ("foo = [];" should do it), then you would be building up that list over time.

Check for a recursive function call loop. Do any functions call themselves? Any chance function A calls function B, which calls function C, which calls function A?

Hrm, looking over it again I'm certain that it's not a list as the only time it does list manipulation is when someone touches a control, if it's left along then the worst it does is create a string with a function, add a few bits and pieces depending on your settings then finishes, presumably destroying the string since it isn't a global variables.
The script should have a ton of memory left for list manipulation (around 4kb), with the lists being no larger than 512 at the absolute maximum.

Is there any way to take like a 'snapshot' of a crashed script to see what is using up it's memory allocation? I see various memory options in the debug menu but I have no idea how I'm supposed to use them.

Thinking about it, it could be any run-time error. However the only one I can think of is a math error which it definitely can't be as there are no divisions performed by this part of the script, the worst is addition and multiplication of integers.
Speaking of which, integers don't crash a script if they overflow do they? Like if an integer were the maximum possible value and I added more onto it, it would just become a negative value instead wouldn't it? I can't think of any part where that would happen either.

I might post the parts of the script that are running, but it's not an easy one to cut to bits...

Aha! I may have figured it out! I will have to leave the script running for a while to be sure, but I think it may be the listens!

I just realised that the createButton() function wasn't keeping a note of the new listen it created, so when the buttons were respawned, it would create a new one without attempting to remove the old (well, it would try to remove listen zero every time).

Fingers crossed it was that causing the problem!

Do listens take up memory in the script as well then do you think, or is there a hard limit to how many can be made before the script crashes?

[edit]
Just read in the documentation, it must have been taking around an hour for the script to fail then, as the limit is 64, that would explain why I never saw it and would be consistent with my log-in times today.
It's always the simplest mistakes =(

If you have too many listens you get "Error too many listens" a "stack heap collision" means the script is out of memory. Without looking at your script I'm guessing that the error is occuring because one of the temporary lists is not clearing and is growing to the point it crashes the script. How are you storing the button keys? In a list? is it being added each time?

How to get a stack heap collision: try to run an operation that requires very long strings to be pushed into the stack or try to put a string longer then the free memory available into memory. Lists cause the same thing to happen.

strings and keys are the same thing (a key is just a specific type of string).

A script has 16k to operate in. In that 16k is the bytecode, the memory, and the stack. It is possible for either the stack to overflow, or a store from the stack to overflow into the stack. If this happens the scirpt crashes.

Something I've learnt in my career as an embedded programmer that they didn't teach me in college - embrace global variables

As a debugging method, you could put in a timer that dumps your lists to open chat every so often so you could visually see if a list is getting overly long/full.

No, I was assuming it was a stack-heap collision because it seemed like the most likely cause (I've been having trouble with them all through this script since the bytecode takes up so much space there isn't much left for manipulation).
It was in fact just listens.
The reason I assumed was because I'd been unable to catch this error occurring while I was online (and it would have taken 64 minutes to occur, so I would be unlikely to still be waiting around when it happened).

It was definitely the listens, as this part's now running happily (still got memory issues, but I'm working on that).