This is an introductory guide to some good techniques for working out common design flaws and errors.

Overflow errorsEdit

Overflow errors are tricky to diagnose because the code that overflows is probably not the code with the bug, but simply an innocent bystander that pushed the almost-full stack over the limit. Overflow bugs would be easy to diagnose if there was a way to step backwards in time from the point of crashing, but there's no way to do that in the grobots debugger. In an emergency an overflow error can be hidden by adding stack dropn (which empties the stack) in your main loop at a time that the stack should be empty. But it's best to track down the root cause since any code that's leaving operands on the stack is often misbehaving in other ways as well. Here's one way to diagnose an overflow error:

  • Examine a crashed cell in the debugger to determine whether it's the main stack or the return stack that overflowed. The main stack is usually the culprit since it's used a lot more often. The remainder of these instructions assume that the main stack is the problem.
  • If you've only changed a few lines of code recently, start by double-checking those lines for silly mistakes.
  • If that fails add stack if pause sync (id number) stack dropn then in various places in your code where the stack should be empty:
#var last-stack 0
 stack if pause sync 1 stack dropn then
 ...some code...
 stack if pause sync 2 stack dropn then
 ...some code...
 stack if pause sync 3 stack dropn then
 ...some code...
  • Run some matches (making sure the report errors option in the view menu is turned on) and wait for the simulation to mysteriously pause itself. Look at all your robots in the debugger and look for one that has just executed pause sync. The next instruction (shown in blue) is the id number indicating which of the pause syncs was triggered. Now you know that the problem occurred between that one and the previously executed one.
  • Either add more of those checks to further narrow where the problem is, look at the offending code for errors, or step through the offending code in the debugger watching the stack in hope of catching it in the act. Looking at the offending items on the stack may help give ideas of what the problem is.

If your editor knows about line numbers (as all editors designed for programming do) then the (id number) can be omitted.