In the 2016 Update of the RoboRIO image, instead of running the frcKillRobot.sh -r -t command to restart robot code, the Java process is just killed and a watchdog checks to see if the program is running, and if not, to start it.
This has the side effect of if the robot crashes, the code will immediately start up again. This is good in some cases, but for cases where the robot crashes upon init (whether it be programmer error or what have you), the crash is on a loop and will write new crash logs to file until the robot program is replaced, or the power to the robot is unplugged.
This can make it hard to identify crash logs. We need a way to detect if the robot crashes consecutively with an identical stacktrace. This can be done by writing the crash conditions to file, and removing the file at bootup. Checking if a) this file exists and b) this file contains an identical exception signature will allow us to determine whether a new crash log should be written.
In the 2016 Update of the RoboRIO image, instead of running the
frcKillRobot.sh -r -tcommand to restart robot code, the Java process is just killed and a watchdog checks to see if the program is running, and if not, to start it.This has the side effect of if the robot crashes, the code will immediately start up again. This is good in some cases, but for cases where the robot crashes upon init (whether it be programmer error or what have you), the crash is on a loop and will write new crash logs to file until the robot program is replaced, or the power to the robot is unplugged.
This can make it hard to identify crash logs. We need a way to detect if the robot crashes consecutively with an identical stacktrace. This can be done by writing the crash conditions to file, and removing the file at bootup. Checking if a) this file exists and b) this file contains an identical exception signature will allow us to determine whether a new crash log should be written.