Robot Code Crashes on cancelAll()

[64bitGPU]

Our robot code will crash whenever we call cancelAll(). I can get the error code but we call this for testing because we have different commands in different modes and we don’t want anything to break when we re-enable. I can send the error code later. By the way we are using the CommandScheduler (new command based stuff) and it crashes on the CommandScheduler.getInstance().cancelAll() call

[NewtonCrosby]

What does the stacktrace have in it?

[64bitGPU]

Error at java.base/java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719): Unhandled exception: java.util.ConcurrentModificationException
        at java.base/java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719)
        at java.base/java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:741)
        at edu.wpi.first.wpilibj2.command.CommandScheduler.cancelAll(CommandScheduler.java:378)
        at frc.robot.Robot.autonomousInit(Robot.java:78)
        at edu.wpi.first.wpilibj.IterativeRobotBase.loopFunc(IterativeRobotBase.java:220)
        at edu.wpi.first.wpilibj.TimedRobot.startCompetition(TimedRobot.java:82)
        at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:276)
        at edu.wpi.first.wpilibj.RobotBase.lambda$startRobot$0(RobotBase.java:329)
        at java.base/java.lang.Thread.run(Thread.java:834)

[NewtonCrosby]

Looks like a bug in the API.

@LinkedHashMap JavaDoc

The iterators returned by the iterator method of the collections returned by all of this class’s collection view methods are fail-fast : if the map is structurally modified at any time after the iterator is created, in any way except through the iterator’s own remove method, the iterator will throw a ConcurrentModificationException . Thus, in the face of concurrent modification, the iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future.

Their code:

public void cancelAll() { for (Command command : m_scheduledCommands.keySet()) { cancel(command); } }
The iterator.get method is structurally modifying the set.

I think that m_scheduledCommands.values() is what they should be iterating over to avoid it.

[64bitGPU]

The structure of the m_scheduledCommands is a Map<Command, CommandState>. So the .keySet() is correct to get the Command. Should I just wait for an update?

[Peter_Johnson]

Fixed in this PR. Will be in the next release.