This has had me and the other programmer on our team pretty stumped. We have this command set up using the limelight that is supposed to turn our drivetrain to the reflective tape. Only problem is, when we press the button bound to this ‘facehub’ command the whole program shuts down and gives me a myriad of errors. Here are a few to note(sorry for horrendous quality):
Then, after changing the button from UP on the DPAD to A i got this new error:
Could you send the code you’re using right now? Sounds like it might be uninitialized buttons.
It would really help if you could post the code, but my guess would be that somehow the command you’re passing to the button’s event handler is uninitialized.
Yes yes of course, dumb of me to ask for help without posting code. https://github.com/rambots/Robot-2022/tree/off-season
Is the uploaded code the version this occurred on? Last commit was 4h ago, this was posted an hour ago
In one of the screenshots I see an error message:
Corrupted double-linked list
I don’t think I’ve ever seen that error message in FRC code. Googling suggests that a native method may be corrupting memory.
Could this line:
public static final Controller<Gamepad.Button, Gamepad.Axis>
Have anything to do with it? I know linked-lists use <>, so that’s my first idea.
I don’t think so. Googling that error message suggests that it’s coming from assertions in the memory management system.
I see that your code uses a lot of static class variables (e.g. faceHub) that would be better as (non-static) final instance variables. I don’t think this is causing your problem, but it’s not best practice to initialize static variables in the constructor.
My thought was that might be a linked list and there could be some weird corruption happening with the bindings.
Since I can’t see your local code: I’d recommend looking through all the lines (i.e. with git diff) that you changed, and from there commenting out any larger changes, i.e. new button bindings or commands.
Is your thought that <> is connected to linked lists? Those are called generics, you can look them up, but the oversimplified version is that they let you write “generic” classes and interfaces which can then be instantiated to work on a specific type (Integer, String, SubsystemBase, etc.). LinkedLists use generics; you use generics to specify what class of objects the list will contain. But they aren’t the only thing to use generics, and the line you pointed out has nothing to do with LinkedLists as far as I can tell
So they’re akin to C++'s templates then–got it, thanks!
I’ve been staring at your code, and the WPILIB code where the crash is, and I’m thinking that the problem may be related to your use of whileHeld with interruptible=false.
driveController.getDPadButton(Direction.UP).whileHeld(faceHub, false);
The whileHeld continually schedules the command, interrupting any previous command with overlapping requirements. In this case, the previous command is the same command, but it isn’t interruptible. WPILIB ought to handle this case, but maybe it doesn’t.
I suggest you either use whenHeld instead, or don’t declare your commands to be non-interruptible, or both. (I’m not sure why you need non-interruptible commands here. They should be the exception, not the rule.)
So try:
driveController.getDPadButton(Direction.UP).whenHeld(faceHub);Aha! I have another theory. In FaceHub, you have:
public void initialize() {
if (hasValidTarget())
controller.setSetpoint(0);
else
this.cancel();
}
I think the problem is that you are calling cancel in the initialize method. In WPILIB, the command’s initialize method is invoked after updating m_scheduledCommands and before updating m_requirements. The cancel method attempts to remove both, but will have nothing to remove for the latter. This will cause exactly the crash observed, because the command will be in m_requirements but not m_scheduledCommands.
See WPILIB issue #4259.
Yeah you definitely have a point, I was treating non interruptible commands like the norm throughout the entirety of the codebase. Also I had no idea where to access the lines of code where the error was generated. Like it was saying “Error at: wplilib.commandbase.command:273” or something like that but i didnt have that as a file. Good to know theres a whole repository with those files.
Thank you for the clear explanation, I see that the Issue #4259 has some suggested mitigations but do you have any idea which would be best in this case?
I’m afraid those are suggestions for the WPILIB team, not workarounds for the end user. My suggestion for you is to not call cancel in initialize. Make isFinished do the work.
I’d just like to put a word of warning for this: execute is called before isFinished so if it is critical that execute is not called (pneumatics for example) then you should wrap the command with a conditional command that has an empty instant command as the other argument (or something similar). You should probably do this even if it is not critical if one cycle of execute is run just for cleanliness.
I was able to recreate the NPE in a test, and am working on a fix.
I wasn’t able to recreate the JVM crash though. Can you post (here, in a DM to me, or whatever you prefer) the JVM log file? It should be in the root directory of the project.
Sorry for the belated response, Sunday I had no access to the laptop and y’know school on Monday. By JVM I assume you’re referring to the Fatal error in the last screenshot right? Where do I go to access the root directory?
So is it unnecessary (or, harmful in this case) to call the cancel method in initialize? Should I just get rid of that line?