JavaVM Crash During Match

At TWIST last weekend (which was amazing!) our robot had a JavaVM crash twice during a match. This was unfortunate as we had to wait for the code to restart before we could continue. To provide some context, there were FMS issues before this match started, and the robots sat on the field for a while as the issues were addressed, which may have included an FMS restart.

I’m fairly certain we are running the latest released versions of everything.

Here’s a transcription (carefully done but by hand) of the associated log entry:

# /tmp/hs_err_pid1828.log # An error report file with more information is saved as:
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again.
#
# C [libntcore.so +0xf7ff0] nt::net::NetworkOutgoingQueue<nt::net::ServerMessage>::SendOutgoing(unsigned long long, bool) + 0x3a8 # Problematic frame:
# Java VM: OpenJDK Client VM (17.0.9.7-frc+0-2024-17.0.9u7-3, mixed mode, emulated-client, serial gc, linux-arm)
# JRE version: OpenJDK Runtime Environment (17.0.9.7) (build 17.0.9.7-frc +0-2024-17.0.9u7-3) # # SIGSEGV (0xb) at pc=0xa9cc9ff0, pid=1828, tid=1980
#
# A fatal error has been detected by the Java Runtime Environment:

I’ve never seen anything like this before. I expect there’s nothing that we can do but thought that the WPILib folks may be interested…

Do you know what fatal error it was reporting?

There’s enough information in whats posted to determine it’s a segmentation fault somewhere in this function.

2 Likes

Can you check the memory usage? We had this same error message during a memory leak, and our solution is switching to rio2.

I’ll check when I next have access to the robot and the driver station logs. We are running on a roboRIO 2. I could see how a memory leak could build up over time. However, while the robot was powered on for a while before the start of this match, we’ve certainly had many situations where the robot was running for much longer.

Memory Free 148 MB. Looks like plenty.