No space left on device error

My team is attempting to deploy code to a roboRio traditionally used for testing purposes in the past (successfully), yet after no known changes to the device (besides our numerous attempts at updating firmware, reimaging, and reinstalling java), we get an error that says:

java.io.IOException: No space left on device
    at java.io.FIleOutputStream.writeBytes(Native Method)
    at java.io.FileOutputStream.write(FileOutputStream.java:307)
    at edu.wpi.first.wpilibj.hal.JNIWrapper.<clinit>(JNIWrapper.java:40)
    at edu.wpi.first.wpilibj.RobotBase.initializeHardwareConfiguration(RobotBase.java:170)
    at edu.wpi.first.wpilibj.RobotBase.main(RobotBase.java:182)

Despite what the error states, the driver station claims that there are 228 MB of disk space left on the roboRio. We have tried this with identical results from multiple computers, both which claim the build was successful upon deploy. It’s the same story whether we use last year’s robot code, an empty brand new project, or code we just wrote. RobotInit doesn’t even start running, and no error output is produced through the network. This message was only discovered after using ssh to manually start the robot code. We have not yet been able to test on another roboRio.
Any ideas? Help would be greatly appreciated.

You could try re-imaging the rio

:eek: :eek:

Have you tried SSH’ing into the RoboRIO directly and checking the free space on the device? Is there a chance your code is flooding logs at a very high rate?

Whoops, looks like I didn’t read the post. :o

If you connect and use the web browser to view the robot’s config page, it will also show you the disk and memory and CPU usage. Please use that to verify the disk free number.

And of course you could check from a shell. If you truly have 100s of MB, you will need to work with the Eclipse folks to determine what the error truly means.

Greg McKaskle

I have experienced this error for this reason:

When the code starts, it extracts the WPILib JNI library to a tmpfs partition (/var/volatile, I believe). If the code crashes in native code, either the JNI library temp file won’t be deleted or a coredump is written to the same temp directory, or both (I can’t remember). The code restarts over and over eventually filling up the temp directory and causing this error.

I’m not sure why your code would be crashing like this, but I would recommend checking to see if /var/volatile is being filled. If so, kill the script that automatically restarts the code, then empty /var/volatile, manually start the code and view the FRC_UserProgram.log file. I have seen some cases where errors are not printed to the driver station, but are printed to the log file.

Let me know if you have any questions.

Turns out the code was lacking the initialization of an array of Talons, which oddly enough wasn’t being caught by the compiler or IDE. Another strange thing was that we were able to run any working code on the roboRio before we ran the broken project, but after that project was ran, all code attempted to be ran would not work.
Thanks for all your help!