New Script Technology causes stack overflowsFiled Under: Weekly Tuesday Dose of goodness
An analysis of the new technologies implemented into StridesScript Engine and ScriptIDE 3.4 has raised some new concerns of the once crash-proof game platform.
Unfortunately, power comes with responsibility and the user has to bear the burden.
Of course, to be fair, there’s no need to be responsible for things the user did not use. Therefore this article only applies to the new set of technologies implemented.
In the past, all strides script calls are non-blocking and they’re automatically pipelined to be processed. Since they’re pipelined, the stack in the code do not have to bear the burden of multiple script calls.
However this meant that the engine was limited to pipelining processing; blocking calls are also important in some cases.
For example, you won’t want a enemies to appear in quick succession. Rather you’d want them to appear all at once.
This problem was resolved initially by placing the enemies off the screen.
However, we might not get lucky when we hit the 3D gameplay era where objects can be spawned right in front of the player without careful timing.
Therefore an initiative was initiated to create a technology that allows blocking calls to be possible. This, in script IDE is known as “Run Script Immediate” or “Run Script Instance Immediate”. The latest “Run Script One Off” also has this run immediate feature.
With this technique, it skips the pipeline processing and go straight into running these actions directly.
This causes another potential problem; that is if there’re nested Immediate runs, there’ll be stack costs involved. And since their stack size is virtually unknown until runtime, the potential danger for a stack overflow is rather high.
So therefore, in order to combat such potential dangers, there’ll be a tool in the future to perform static analysis and data flow analysis on such nested calls to ascertain if there’ll be any potential stack overflows or not.
Stack overflows are scary types of crashes which is very much alike out of memory in the heap, but it’s far too sensitive (since it’s limited) and minor changes can lead to it easily.
The other way would be, produce a set of best practices for operating StridesScript engine.
1) Use Run Script Immediate only for loading resources
2) Use Run Script or Run Script Instance or Run Script One Off without immediate for all other scripts
3) Limit the amount of Run Script Immediate
Power comes with Responsibility. Only the ones who are prepared will be able to handle this power with the right attitude and sense of responsibility.
Regards,
Jeremy
- Permalink
- Admin
- 2 Jun 2009 1:48 PM
- Comments (0)