Currently, if a trajectory fails to generate when using the Java API, a segfault occurs and causes the JVM to crash without any way to recover. This failure state happens mainly when a set of waypoints is supplied that cannot be satisfied given the constraints specified.
When this occurs, the problem is usually visible until the new code is loaded on the robot and fails to start. This also has the unfortunate side effect of causing the WPILib and NetworkTables native library temp files to not be deleted, eventually filling up the /tmp partition as the code restarts repeatedly.
It would be better if an exception could be thrown to allow the robot code (or tests that are running at compile time) to handle this situation gracefully.
Here is an example of the error message that is printed when I attempted to generate an impossible trajectory:
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f753bdfe00c, pid=13239, tid=0x00007f758839c700
#
# JRE version: OpenJDK Runtime Environment (8.0_92-b14) (build 1.8.0_92-b14)
# Java VM: OpenJDK 64-Bit Server VM (25.92-b14 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [pathfinderJNI6799153841197995727.so+0x700c] pf_trajectory_fromSecondOrderFilter+0xb2
#
# Core dump written. Default location: /path/to/Code/2016/FRC/CMonster2016/core or core.13239
#
# An error report file with more information is saved as:
# /path/to/Code/2016/FRC/CMonster2016/hs_err_pid13239.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Currently, if a trajectory fails to generate when using the Java API, a segfault occurs and causes the JVM to crash without any way to recover. This failure state happens mainly when a set of waypoints is supplied that cannot be satisfied given the constraints specified.
When this occurs, the problem is usually visible until the new code is loaded on the robot and fails to start. This also has the unfortunate side effect of causing the WPILib and NetworkTables native library temp files to not be deleted, eventually filling up the /tmp partition as the code restarts repeatedly.
It would be better if an exception could be thrown to allow the robot code (or tests that are running at compile time) to handle this situation gracefully.
Here is an example of the error message that is printed when I attempted to generate an impossible trajectory: