The forked VM terminated without saying properly goodbye. VM crash or System.exit called

Please help me to solve this issue. I do not exactly understand what the error in the log means.

[INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 21.749s [INFO] Finished at: Thu Apr 24 10:10:20 IST 2014 [INFO] Final Memory: 15M/37M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on project samples.simpleforwarding: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? [ERROR] Command wascmd.exe /X /C ""C:Program FilesJavajdk1.7.0_55jrebinjava" -Xmx1024m -XX:MaxPermSize=256m -jar E:OpenDayLightcontrolleropendaylightsamplessimpleforwardingtargetsurefiresurefirebooter53410321571238933.jar E:OpenDayLightcontrolleropendaylightsamplessimpleforwardingtargetsurefiresurefire86076271125218001tmp E:OpenDayLightcontrolleropendaylightsamplessimpleforwardingtargetsurefiresurefire_01846991116135903536tmp" [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException

Please re-run Maven with -e and -X like the output suggests, and paste what it gives you. Also, are you building your own code or an existing library? If you are building your own code, are you calling System.exit(int) anywhere? If you are building an existing library, where did you get the source?
– Dylon
Apr 24 '14 at 4:53

@Dylon Edwards: It's an existing source code, OpenDayLight project for SDN implementation.
– astack
Apr 24 '14 at 5:13

A recent scenario I had that reproduces the issue was when I ran test suites from xml files. In case a xml file defines a class that no longer exists, or refers to the old fully-qualified name of a class has been moved, then the JVM fails to load the class. This results in the strange message you've observed. Looking closer to any stack-trace could help you identify such issues, no need to pass the -e or -X switches in this case.
– Ivaylo Slavov
Sep 18 '14 at 7:52

@astack what came out to be the solution for this? could you mark an answer or write your own please.
– nullpointer
Oct 13 '16 at 15:12

23 Answers
23

I had the same problem and solved by adding:

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

The whole plugin element is:

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <forkCount>3</forkCount> <reuseForks>true</reuseForks> <argLine>-Xmx1024m -XX:MaxPermSize=256m</argLine> </configuration> </plugin>

+1 I used this snippet, verbatim, and it fixed my issue with Travis-CI. We weren't getting this on any of our developer's workstations.
– Michael Mügge
Feb 17 '16 at 20:00

It worked for me, too, on a machine with insufficient memory resources for the tasks.
– Mateva
Nov 7 '17 at 16:21

Above did not fix the issue for me. This issue 'may' occur when one of the dependencies(jar etc) in .m2 is corrupt. Deleting ~/.m2/repository rm -rf ~/.m2/repository and then mvn install resolved it for me.
– ch4nd4n
Jun 12 at 12:16

.m2

rm -rf ~/.m2/repository

mvn install

This part of the Surefire FAQ could help you:

Surefire fails with the message "The forked VM terminated without properly saying goodbye"

Surefire does not support tests or any referenced libraries calling System.exit() at any time. If they do so, they are incompatible with surefire and you should probably file an issue with the library/vendor. Alternatively the forked VM could also crash for a number of reasons, which can also make this issue happen. Look for the classical "hs_err*" files indicating VM crashes or examine the log output from running maven when the tests execute. Some "extraordinary" output from crashing processes may be dumped to the console/log. If this happens on a CI environment and only after some time runs there is a fair chance your test suite is leaking some kind of OS-level resource that makes things worse for every run. Regular os-level monitoring tools may give you some indication.

I had the same issue today and for me the real problem was reported further up in the log with message Cannot use a threadCount parameter less than 1; 1 > 0.
When adding <threadCount>1</threadCount> in the surefire-plugin config the other error disappeared.

Cannot use a threadCount parameter less than 1; 1 > 0

<threadCount>1</threadCount>

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.18.1</version> <dependencies> <dependency> <groupId>org.apache.maven.surefire</groupId> <artifactId>surefire-junit47</artifactId> <version>2.18.1</version> </dependency> <dependency> <groupId>org.apache.maven.surefire</groupId> <artifactId>surefire-testng</artifactId> <version>2.18.1</version> </dependency> </dependencies> <configuration> <threadCount>1</threadCount> </configuration> </plugin>

...and yes, I am using both junit and testng in this test framework for backward compatibility reasons.

Had similar problem when running mvn command with Jacoco plugin on JDK 1.8.0_65

[INFO] A fatal error has been detected by the Java Runtime Environment: JRE version: Java(TM) SE Runtime Environment (8.0_65-b17) (build 1.8.0_65-b17)......... Problematic frame: PhaseIdealLoop::build_loop_late_post(Node*)+0x144 ............ ............ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) on project The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

There was a bug in JDK https://bugs.openjdk.java.net/browse/JDK-8081379

And the solution was to run mvn clean install with param -XX:-UseLoopPredicate

Or just make an update to JDK (I think newer minor version works)

You need to check if your machine is 64 bit or 32bit. If your machine is 32 bit then your memory argument should not exceed 4096, even it should be below 4 GB.
but if your machine is 64 bit then, install Java 64 bit and provide JAVA_HOME in mvn.bat which point to java 64 bit installation.

Isn't 32 bit java complain about incorrect option?
– om-nom-nom
Apr 8 '15 at 11:25

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.

I recently stuck in with this error while building my containerized jar applications with Bamboo:

org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM terminated without properly saying goodbye

After many hours of researching I fixed it. And I thought it would be useful to share my solution here.

So the error happen every time when bamboo run mvn clean package command for java applications in the docker containers. I am no Maven expert but the trouble was in Surefire and Junit4 plugins included in spring-boot as maven dependency.

mvn clean package

To fix it you need to replace Junit4 for Junit5 and override Surefire plugin in you pom.xml.

pom.xml

1.Inside spring boot dependency insert exclusion:

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope>  </dependency>

2. Add new Junit5 dependencies:

<dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-api</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-engine</artifactId> <version>5.1.0</version> <scope>test</scope> </dependency> <dependency> <groupId>org.junit.vintage</groupId> <artifactId>junit-vintage-engine</artifactId> <version>5.1.0</version> <scope>test</scope> </dependency> <dependency> <groupId>org.junit.platform</groupId> <artifactId>junit-platform-launcher</artifactId> <version>1.1.0</version> <scope>test</scope> </dependency> <dependency> <groupId>org.junit.platform</groupId> <artifactId>junit-platform-runner</artifactId> <version>1.1.0</version> <scope>test</scope> </dependency> <dependency> <groupId>org.junit.platform</groupId> <artifactId>junit-platform-surefire-provider</artifactId> <version>1.1.0</version> <scope>test</scope> </dependency>

3. Insert new plugin inside plugins section

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-failsafe-plugin</artifactId> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.19.1</version> <dependencies> <dependency> <groupId>org.junit.platform</groupId> <artifactId>junit-platform-surefire-provider</artifactId> <version>1.1.0</version> </dependency> <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-engine</artifactId> <version>5.1.0</version> </dependency> </dependencies> </plugin>

That's should be enough to repair bamboo builds. Don't forget also transform all Junit4 tests to support Junit5.

May be it is because you have applied some changes in your project and did not update their all references.

In my case I was getting this error because I have updated package names in my project but I forgot to update their references in TestNG.xml file. By correcting it, I solved this error.

I experienced this error after a static member variable in my test class called a method to create an object (which was used in test cases throughout the class), and the method caused an exception.

// Object created inside test class by calling a static getter. // Exception thrown in getter: private static Object someObject = SomeObject.getObject(...); // ... <Object later used in class>

Some fixes include recreating the object inside each test case and catching any exceptions accordingly. Or by initializing the object inside an @BeforeTest method and ensuring that it is built properly.

In my case, the issue was related to workspace path which was to much long. So I did a path refactoring and this solved the issue to me.

Was that on a windows machine?
– hithwen
May 17 '16 at 1:42

Yes, it is running in Windows .
– thiago-devel
May 17 '16 at 19:05

How did you found that?
– dzieciou
Jun 6 '16 at 5:52

When I encountered this error it was due to my ulimit for open files (ulimit -n) being too low. It had (somehow) got set to only 256:

ulimit -n

% ulimit -n 256

The error went away after I increased the limit:

% ulimit -n 3072 % ulimit -n 3072

Your system might not allow the limit to be set so high. e.g., this happens when I try to use a larger number:

% ulimit -n 3073 ulimit: setrlimit failed: invalid argument

Or this might be lower than your existing limit and you could be facing a different root cause.

In my case, I forgot to add the dependency in the pom:

<dependency> <groupId>org.aspectj</groupId> <artifactId>aspectjweaver</artifactId> <version>1.8.5</version> </dependency>

Just make sure that you pick the right version (as for today 1.8.9 is latest)

I ran into this problem during Jenkins builds on an Ubuntu machine.

/var/log/syslog reported Out of memory: Kill process 19557 (java) score 207 or sacrifice child.

/var/log/syslog

Out of memory: Kill process 19557 (java) score 207 or sacrifice child

I therefore gave the Ubuntu machine more swap space. Since then, the problem is gone.

I also experienced this - but in my case I had written a custom hook for cucumber

public class MappingFormatter implements gherkin.formatter.Formatter {

...

one of my methods was producing a Null pointer exception, which caused the surefire to exit without logging the error.

Recently travis killed the execution of a test (without having changed anything related (and successful builds on developer machines!)), thus BUILD FAILURE.
One of the causes was this (see @agudian answer):

Surefire does not support tests or any referenced libraries calling System.exit()`

(since the test class indeed called System.exit(-1)).

System.exit(-1)

Using a simple return statement instead helps.

return

To make travis happy again, I also had to add the surefire parameters (<argLine>) provided by @xiaohuo. (also, I had to remove -XX:MaxPermSize=256m to be able to build on one of my desktops)

<argLine>

-XX:MaxPermSize=256m

Doing only one of the two things didn't worked.

For more background read When should we call System.exit in Java.

This could also happen due to a totally different issue. For example in my case our Jenkins build was failing intermittently while executing tests without any reason.

I sifted through our tests to find any occurrence of System.exit() but there was none.

System.exit()

After more digging I found out that this could be happening because of a JDK bug which could have caused this regression.

JDK-6675699

I am still working on making this fix in our builds, will come back and update the thread again.

This may occur due to inadequate memory. Make sure you don't have any applications running on background while running mvn. In my case Firefox was running on background with high memory usage.

This will work definitely.....

Add the below lines in the POM file and give a build.

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.19.1</version> <configuration> <trimStackTrace>false</trimStackTrace> <includes> <include>**/*Test.class</include> </includes> </configuration> </plugin>

Did encounter the same problem as I was trying to compile a maven project set to 1.7 on a windows 10 environment running JAVA = 1.8.

I resolved it by changing the java version from 1.7 to 1.8 as shown below.

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.3</version> <configuration> <source>1.8</source> <target>1.8</target> </configuration> </plugin>

I have very similar problem (Maven build and maven-failsafe-plugin - The forked VM terminated without properly saying goodbye) and found three solutions which working for me:

Problem is with maven plugin maven-surefire-plugin only in version 2.20.1 and 2.21.0. I checked and you use version 2.20.1.

Upgrade plugin version to 2.22.0. Add in pom.xml:

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.22.0</version> </plugin>

Downgrade plugin version to 2.20. Add in pom.xml:

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.20</version> </plugin>

Use plugin configuration testFailureIgnore. Add in pom.xml:

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <testFailureIgnore>true</testFailureIgnore> </configuration> </plugin>

"Caused by: java.util.concurrent.ExecutionException: java.lang.RuntimeException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?"

This issue can be occur if you use non compatible version of java. Like uses new version of java while code support some other version.

The forked VM terminated without saying properly goodbye. VM crash or System.exit called

The way to prevent this error is to run your IDE as Administrator.

Well, it works for me (Eclipse IDE).
– Juha Hanka
Feb 8 at 11:47

for me it worked with

mvn clean install -DskipTests -e

Skipping tests is a way to sweep problem under the rug, not fix it.
– om-nom-nom
Apr 8 '15 at 11:24

I love his thinking :). Made my day.
– sorrymissjackson
Oct 7 '16 at 6:21

I worked for me too ^^
– Patryk Dobrowolski
Mar 20 at 10:50

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Search This Blog

Mgiyuk