What does "CPU fault, rebooting" mean, and how do I fix it?
What happens in a fault
- The program stops at the bad instruction.
- The CPU is down for a second (20 ticks). Its parts keep their last commands meanwhile, so a bot that faults at full throttle drives on blind.
- The program starts again from the top, with every variable reset.
A bot that faults again and again loses a second each time and forgets everything it had worked out. If it faults soon after each restart, it can look as if it's doing nothing at all.
Where to see it
- Events beside the Arena's field: "Scout CPU fault, rebooting". Click it to replay the moment before at half speed.
- The timeline under the field has a mark at each fault.
- The Match panel, after a test, shows each bot's number of faults.
- Your program can read the count:
cpu.faultsin Python, JavaScript and Lua (see the Reference for your language). It counts every reboot this match, so it survives the restart:
if cpu.faults > 0:
log("rebooted {} times", cpu.faults)
Find the cause
- Check your indexes. Every list or array index must be inside it. A loop that goes one step too far, or an index worked out from a reading, are the usual suspects. Log the index just before you use it:
log("slot {} of {}", i, len(targets))
- Check how deep your calls go. Function calls use the stack: nest them too deep and it runs out.
- Read the log just before the fault. In Bot logs, the last lines before the fault show what the program was doing. Step back with ← in the Arena to the tick before.
- Rebuild the moment in the Test arena and run it until the fault is gone.
A fault inside a log line doesn't reboot the bot: only that log is dropped, and the log says so.
In assembly, a fault also comes from running past the end of the program, a jump outside it, a load or store outside RAM, or an illegal instruction.