Strategy for debugging surefire “The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?”

Question

I am working on a rather complex java project with many dependencies and many unit tests.

I am using java 1.6.0_65 on mac (mavericks) with maven 3.0.5 with maven-sur

Answer 1

If you are using Visual Studio Code

I did not do any changes in the pom.xml file or updated any dependency versions
Adding this line to settings.json of Visual Studio Code solved the problem.

"maven.executable.options": "-DforkCount=0",

Answer 2

In my case the configuration forkedProcessExitTimeoutInSeconds for the maven-surefire-plugin helps. The default value are since maven-surefire-plugin:2.20.1 30 seconds. My project gots very time consuming test and so the forked JVM chrashes. Configure the plugin in the pom with the following property solves the problem.

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
                <forkedProcessExitTimeoutInSeconds>120</forkedProcessExitTimeoutInSeconds>
        </configuration>
</plugin>

Answer 3

JVM options that can help:

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=c:/dumps/

Note: You can use forward slashes.
Note 2: Make sure the folder exists and that the process has write permission. On recent windows systems, C:\ is write protected.
Note 3: Make sure you have enough free space to write the dump. The Java 9 documentation mentions that the system's temp folder will be used when the disk is full.

If there is no dump file, then you JVM didn't run out of memory.

The next option is -XX:ErrorFile= which allows to the JVM to log fatal errors.

-XX:+ShowMessageBoxOnError shows an error dialog if the JVM crashes.

Note: You can change the flags of a running JVM using the jinfo command.

Pass these options to Maven Surefire via the argLine option:

<build>
    <plugins>
        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <configuration>
                <!-- -XX:HeapDumpPath=C:\ -XX:+ShowMessageBoxOnError  -->
                <argLine>@{argLine} -XX:+HeapDumpOnOutOfMemoryError -Xmx1g -XX:HeapDumpPath=H:/dumps/ -XX:ErrorFile=H:/dumps/ -XX:+ShowMessageBoxOnError</argLine>
            </configuration>
        </plugin>
    </plugins>
</build>

The strange @{argLine} at the beginning allows other plugins like Jacoco to inject their options. For this to work, you need to add an empty property:

<properties>
    <argLine></argLine> <!-- Fallback when Jacoco isn't active. -->
</properties>

You can verify that it works when the error happens: Maven will then dump the whole command line used to start the forked JVM.

Answer 4

Writing here the strategy that i used to help others who are stuck with this problem.

It is possible to leverage the SecurityManager to throw an exception when System.exit() is called. you can then examine the stack trace to see exactly who called exit(). This is especially useful if the call to exit was made from code hidden inside one of the jars you are depending on and not from your own code.

private static void forbidSystemExitCall() {
    final SecurityManager securityManager = new SecurityManager() {
        public void checkPermission( Permission permission ) {
            if( permission.getName().startsWith("exitVM") ) {
                throw new RuntimeException("Something called exit ") ;
            }
        }
    } ;
    System.setSecurityManager( securityManager ) ;
}  

Answer 5

What you may want to check is the argline setting for surefire or failsafe in build/pluging/plugin config in your pom. I had something improper in there that caused the forked vm to fail (Ironically, i put maven.failsafe.debug in there to help debug an earlier forking crash).

Answer 6

If anyone is including a custom argLine argument, you must reconsider because it is likely the source of your issues with the memory allocation.

For Example (I used to have):

<argLine>XX:MaxPermSize=4096m ${argLine}</argLine>

Now I use hard specified values:

<argLine>-Xmx1024m -XX:MaxPermSize=256m</argLine>

For whatever reason, Applications that integrate with Surefire such as Jacoco, dont request enough memory to coexist with the testing that happens at build time.

(more information can also be found at this s.o. question (1))

(1)-maven jacoco: not generating code coverage report