Code Gremlins

Technical Programming
1

At competition today, we has a problem where when we put our robot on the field and turned it on, it would run through all of RobotInit but then, at the end, throw an error at RobotBase:249 saying that it had a NumberFormatException with " (Yes, the literal quotation mark. Sorry that I don’t have the actual text of the error.) The strange part was that there was no trace whatsoever back to code we had written, it was all apparently within RobotBase. We also hadn’t deployed since the robot was last functional, meaning that this was an arbitraily timed error. We rebooted the computer, robot, and driver station, and redeployed code, to no avail. The only thing that did work was reverting back to the last commit and then retyping all changes we made. I call this “code gremlins” because there’s no rhyme or reason to this whatsoever, the code just broke without us even deploying. Here’s the diff page that shows everything that was reverted, and has the haunted code in case you want to see if it’s haunted on all RIOs or just ours, and here’s the relevant few lines of RobotBase, which appear to be just the generic error reporting lines.


boolean errorOnExit = false;
    try {
      System.out.println("********** Robot program starting **********");
      robot.startCompetition();
    } catch (Throwable throwable) {
      DriverStation.reportError(
          "ERROR Unhandled exception: " + throwable.toString() + " at "
              + Arrays.toString(throwable.getStackTrace()), false);
      errorOnExit = true;
    } finally {
      // startCompetition never returns unless exception occurs....
      System.err.println("WARNING: Robots don't quit!");
      if (errorOnExit) {
        System.err
            .println("---> The startCompetition() method (or methods called by it) should have "
                + "handled the exception above.");
      } else {
        System.err.println("---> Unexpected return from startCompetition() method.");
      }
    }

Any suggestions? Anyone seen this before? I’d like to avoid it happening again as it disabled us for a match.

2

I have no familiarity with the MappedSubsystem support that you are using and your library is missing some of the referenced source code (I suspect it is generated source as part of your build from the cfg file). Also, not having the stack trace makes diagnosis difficult.

However, it appears to me that it is the parsing of your cfg file that is failing. You did add this bit to the cfg file:


intake {
	mechanism {}
	fixed_victor {
		port: 2
		inverted: false
}

I do not know why it would have trouble parsing the 2 or any of the rest of this as it looks consistent with the rest of the file. There were a few other changes to the file too but they look like they should be good.

I also took a look at your csv files as those would be the other obvious candidates for a parse failure but saw nothing obvious.

You should reproduce the error and capture the stack trace. That should point to the code that actually threw the exception that was caught and reported by RobotBase. Failing that, you could try each of the cfg and csv changes one by one to see when the error first appears.

Hope this helps,
Steve

3

The missing code is generated from our .proto files, just run ./gradlew build to generate them. The thing is, there was no stack trace. The error started and ended in RobotBase. I know what errors in the config file look like because we read it in a try/catch block, but this error didn’t really have a trace, it stayed in RobotBase.

4

Are you running in an IDE that allows you to debug and have the wpilib.sources classpath variable defined to ~/wpilib/java/current/lib/WPILib-sources.jar? If so, you may be able to set break on:

      DriverStation.reportError(
          "ERROR Unhandled exception: " + throwable.toString() + " at "
              + Arrays.toString(throwable.getStackTrace()), false);

and run in debug mode to better inspect throwable. Perhaps that might reveal more information.

5

This is very odd. I am familiar with the code jweston points out. It is in the catch for robot.startCompetition() that only ends if there is an uncaught exception. Check the driver station log closely for a stack trace. The throwable.getStackTrace() call should have produced one. I say check carefully because in my experience the stack traces in the driver station console tend to lose their line breaks. It ends up not really looking like a stack trace, is hard to read, but the information is there.

It is possible that whoever is producing the NumberFormatException is suppressing the stack trace but that would be really odd.

If you are in Eclipse and do attach the debugger you can set a break point on any caught or uncaught NumberFormatException and catch the culprit in the act.

Steve