A catchable stack/heap collision
tracked
Artesia Heartsong
I'm pretty sure many of us hate this happening. All kinds of workaround solutions like a script checking on timer() base if another is still running seems quite old school and inefficient too.
How to do it, no idea but suggestions welcome. Pure random and probably imaginary idea: a new event function - or even state - that does run regardless, and then can properly do the necessary work?
Log In
Maestro Linden
marked this post as
tracked
nya Resident
with SLua pcalls maybe
Peter Stindberg
That would be rather nice to have indeed. Since a stack/heap-colliion literally means the script has run out of memory, there would need to be some kind of "grace" memory that would allow the script (limited) functionality to get rid of large lists, strings, etc.
In the meantime, take a look at llGetScriptState and llResetOtherScript, with which you can build a watchdog framework.
Nelson Jenkins
Peter Stindberg If you trust the dead link from 2009 on the wiki page for
llGetFreeMemory
, Mono supposedly lets you briefly exceed 64k (then presumably runs a last-ditch garbage collection), although it's probably difficult to observe. So a try-catch for memory overflows should be theoretically possible. The simplest solution might just be to drop any variables defined in the try block, which shouldn't be too difficult...?Pazako Karu
Nelson Jenkins I can believe this, especially since I have written a function which uses too much memory in one call and it doesn't crash if I put llSleep(1/45.0) in front of it, but will if I don't. That sleep is minimum, one frame, so as long as its back within range within a frame, it doesn't crash.
I forget the specific use case, but I believe it was to get the size of a large string or list that was already in memory, but couldn't be fit twice (to be used in a function call). If you have a one-liner that can use and finish with a large chunk of memory quickly, this might be a hack for you.
Artesia Heartsong
Pazako Karu Tried that, but llSleep for (more) than a frame did not free memory. Even in some cases leaving the event and entering another (timer, or even linkset_data), did not free up quickly enough. Though I only know one case.