On the quality and complexity of software within FRC

[Peter Johnson]

Originally Posted by Thad House

Whats also great about the WPILib is that whenever you initialize a digital port, delete it, and create a new one, the HAL leaks 6 bytes. Now since many teams don't do this, its not a big deal, but still, its a little odd that an official program has a memory leak, even if it is such a small rare one.

Note that at the HAL level, freeDIO() is the opposite of allocateDIO(), and not the opposite of initializeDigitalPort(). The initializeDigitalPort function allocates the memory you're talking about, and was only intended to be called once (ever) per port, with the caller being responsible for saving the resulting pointer across multiple uses. The lack of an uninit function to free the memory in question is admittedly poor API design, but it's worth noting that the higher level WPILib classes use the HAL consistent with the above (call init once, then just use allocate/free), and thus have no memory leaks in this case even if you create/destroy multiple times per port.

I've found that the WPI folks are very welcoming of patches... I'm sure a patch to add appropriate uninit functions to the HAL would be accepted in short order.

[Thad House]

Originally Posted by Peter Johnson

Note that at the HAL level, freeDIO() is the opposite of allocateDIO(), and not the opposite of initializeDigitalPort(). The initializeDigitalPort function allocates the memory you're talking about, and was only intended to be called once (ever) per port, with the caller being responsible for saving the resulting pointer across multiple uses. The lack of an uninit function to free the memory in question is admittedly poor API design, but it's worth noting that the higher level WPILib classes use the HAL consistent with the above (call init once, then just use allocate/free), and thus have no memory leaks in this case even if you create/destroy multiple times per port.

I've found that the WPI folks are very welcoming of patches... I'm sure a patch to add appropriate uninit functions to the HAL would be accepted in short order.

However, if you don't keep the same digital input, and instead go new, it does initialize a new digital port. So calling
Talon t = new Talon(0);
t.free();
t = new Talon(0);

Leaks the memory. Because InitDigitalPort always returns a new digital port, instead of reusing an old one. At least on the java side. And t.free() does not actually release the digital port structure.

I have a few bugs I plan on submitting to WPI that I have found.


I do want to say thank you for doing the python port. I have been able to use that for some help as well, and am implementing the DotNet simulator to use a dictionary similar to the python one, and it should be directly compatible with the websim api.