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

Question

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 Files\Java\jdk1.7.0_55\jre\bin\java" -Xmx1024m -XX:MaxPermSize=256m -jar E:\OpenDayLight\controller\opendaylight\samples\simpleforwarding\target\surefire\surefirebooter53410321571238933.jar E:\OpenDayLight\controller\opendaylight\samples\simpleforwarding\target\surefire\surefire86076271125218001tmp E:\OpenDayLight\controller\opendaylight\samples\simpleforwarding\target\surefire\surefire_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

Woods

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? – Presumptive

@Presumptive Edwards: It's an existing source code, OpenDayLight project for SDN implementation. – Woods

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. – Trometer

@Woods what came out to be the solution for this? could you mark an answer or write your own please. – Clougher

Do you try this? ``` <build> <pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>version</version> </plugin> </plugins> </pluginManagement> </build> ``` – Patsis

I am still getting this error. none of the the solution mentioned worked for me. I am using java 15 and maven surefire plug in 3.0.0-M5. – Lutetium

Were you able to fix it @SourabhRoy ? – Matrix

Answer 1

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>

Zoomorphism

+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. – Fulltime

It worked for me, too, on a machine with insufficient memory resources for the tasks. – Oconner

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. – Luck

Copy and pasted this into my pom file and it worked like a charm, thanks – Phalansterian

OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 – Wheaton

+1 - solved it for me while following John Thompsons Spring framework Beginner to Guru guide and integrating "Fetenarchiv" (a Spring Pet Clinic "Fork" with Maven build management tool) into continuous integration with CircleCI. – Zeuxis

Could someone explain what it actually does and what effects does it have? – Raptorial

I am getting this even I added xmx and xxmaxperspace – Deuteranope

Note that it can hurt jacoco plugin execution (I ran into it), see https://mcmap.net/q/100832/-jacoco-not-generating-jacoco-exec-until-after-skipping-jacoco-execution. – Dissymmetry

One more point to add if there is a dependency on test cases where they cant be run in parallel then one should use only forkCount as 1. I was struggling but was able to resolve in my project helping local businesses : imobilenumbertracker.com/businessescategories – Wilkens

Thank u friend it worked for me, just pasted above code as it is in pom file it is worked – Lachish

It worked for me like a charm!! so what I assume ..it is giving more memory to the task..but I am also getting this [ERROR] OpenJDK 64-Bit Server VM warning: Ignoring option MaxPermSize; support was removed in 8.0 in the log..what is its signficance..the build was successful though..I am running on jdk11 – Automotive

Removing the option -XX:-UseSplitVerifier in <argLine> worked for me. I am upgrading my codebase to AdoptOpenJDK 11 and this option was deprecated in JDK 1.8 – Exhilaration

This will not work very well if you have JaCoCo plugin installed. JaCoCo will stop to report the coverage. From JaCoCo: you must not use a forkCount of 0 or set the forkMode to never as this would prevent the execution of the tests with the javaagent set and no coverage would be recorded. – Salespeople

Answer 2

In my case the issue was related to too long log outputting into IntelliJ IDEA console (OS windows 10).

Command:

mvn clean install

This command solved the issue to me:

mvn clean install > log-file.log

Greenebaum

The logs being too long was the problem for me too! Redirecting to a logfile did not help. Changing some of the most common logging statements, from info to debug, solved the problem – Leffert

too much logging was real problem in my case!! – Fryer

Don't forget error stream too: mvn clean test 2>err.txt 1>out.txt or mvn clean test > out.txt 2>&1 or mvn clean test 2>&1 | tee out.txt While redirecting, you can watch output in other console with less +F out.txt – Stonefly

For me, switching from windows cmd to Intellij console solved it. – Disfranchise

redirecting to log file worked with maven 3.6.2. Or just using maven 3.1.1 also solves the problem – Matteroffact

Indeed, redirecting to log file resolves this issue. – Trichromatism

I got in the same day 2 different PCs with same Windows 10, maven and IntelliJ versions installed and this only occurred in one of the PCs, so it is a bit odd. Nevertheless the log redirect worked for the one with the issue. – Liverpudlian

THANK YOU. Also, this is very depressing. – Nativity

very odd message that console log fails the entire build process, there should have been a way to turn off the debug message during running the tests – Conscious

I got the same error whilst using Cmder (Windows command line replacement). Mikhail's solution worked there too! – Butylene

This worked like magic!!!!l. Alternatively I tried diabling logging in spring application.yaml config.. and it worked – Heidt

So, this also works for me. But it is not a workable solution. Having to open a file to inspect the logging of my unit test, pipelines, etc. This answer to another post https://mcmap.net/q/100833/-strategy-for-debugging-surefire-quot-the-forked-vm-terminated-without-saying-properly-goodbye-vm-crash-or-system-exit-called-quot is about the same problem and mentions the versions in a solution above. The lowered the timeout in that version according to the post. So setting a higher timeout makes sense. And it works! – Dipsomania

Where can we find log-file.log after the build? – Fining

@Fining At the same path where you executed the command – Bugaboo

you all are genius. mvn clean test 2>err.txt 1>out.txt worked for me. – Length

In PowerShell, redirect errors and normal output to the same file with mvn clean test 2>&1 > out.txt – Mirador

Answer 3

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 description

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.

Solution 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>

Solution 2

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>

Solution 3

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>

Styx

For me this combination worked thanks : <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.22.1</version> <configuration> <testFailureIgnore>true</testFailureIgnore> </configuration> </plugin> – Finespun

Thanks for this, using maven:3.6.0-jdk-10 Docker image and upgrading to version 3.0.0-M3 of maven-surefire-plugin resolved for me as well. – Houselights

In regards to Solution 3: Can we really say that ignoring test failures is a solution? What's the point of having tests if their result is meaningless? – Provincialism

I've just upgraded maven-surefire-plugin to 2.22.2 and works fine! – Hassan

Yup! Upgrading to v2.22.2 of surefire solved it for me too. Thx! – Vernation

@Provincialism The option testFailureIgnore can be handy if you want your build server to mark the build as "unstable" in case of test failures, rather than "failed". It only makes sense if your build system is configured to check JUnit's XML files though. – Maryalice

I get this error with Surefire v2.22.2. :( – Ziwot

Solution 1 'Upgrade plugin version to 2.22.0.' solved the problem for me. – Giuseppe

I get this error with version 2.22.0 – Statue

The first solution worked for me as well. – Monandrous

Answer 4

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.

Dougald

For me it was neither of the possible causes mentioned. Instead the project had JVM parameters specified for the surefire plugin that had become deprecated with update to Java 11 and caused the JVM that was created ot run the tests to exit immediately at startup. – Lew

Answer 5

As of today (10/30/2018), we noticed our builds breaking in Jenkins with this error.

The error is a bit misleading and required looking at the output of the dump in target/surefire-reports/ to see the following error message:

Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter

That lead me to the following SO post which mentions a possible bug in OpenJDK 181: Maven surefire could not find ForkedBooter class

Either of the fixes in that post solve my issue. To be specific, I used either one of these:

1. Switching from building in the docker container maven:3.5.4-jdk-8 to maven:3.5.4-jdk-8-alpine
2. Overriding Spring Boot's class loader detailed here: https://mcmap.net/q/100836/-spring-boot-fails-to-run-maven-surefire-plugin-classnotfoundexception-org-apache-maven-surefire-booter-forkedbooter

Pinzler

Thanks. Switching from 1.8.0_161-b12 to 11.0.1+13 helped in our case. – Balcony

This is the exact problem I was facing on my Jenkins and it's resolved now. Thanks. – Fencesitter

OP had another error message: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? – Shuler

@PetroCliff I acknowledged that was the error I was also getting when I said "we noticed our builds breaking in Jenkins with this error". I then proceeded to explain that the error was misleading and that the actual error was in surefire-reports. – Pinzler

Answer 6

My scenario is

• My test has lots of log output (and I mean a lot !)
• Surefire plugin v2.22.2
• The error only happens from inside the IDE, not if the mvn command is executed from a command line.
• no sign of any .dump file from Surefire plugin or traditional hs_err crash files from Java binary.

Two things consistently worked as solutions for me (they are alternatives):

1. Do not use forking: set Surefire plugin property forkcount = 0.
2. increase Surefire plugin property forkedProcessExitTimeoutInSeconds from 30 secs to say 300 secs. The plugin documentation says that if this timeout is hit you'll see error message There was a timeout in the fork. I saw no such error message, yet it consistently fixes the problem to increase this timeout value.

You would probably want to use solution (2) as forking is desirable.

Why?

My theory is that if lots of log output then there's still lots of processing that needs to be done on fork shutdown (in particular if you are running inside an IDE which captures the output and possibly uses a memory mapped files for its window content). In short: at the time the test is finished there's still a lot of text waiting to be forwarded into your IDE. It seems 30s simply isn't enough for this.

This also explains why some devs will see the problem, while others not. How much output processing is left to do at the time of test finish is probably a function of cpu power, disk speed, etc.

If I'm right in this - cannot prove it - then all suggestions like redirecting the log output and decreasing the logging level are IMO treating the symptom, not the cause.

Patti

I"m surprised this answer has not been upvoted more. Many higher rated solutions refer to redirecting output to a logfile which will did work for me. The question is why? I noticed that the test suite ran a bit faster when outputting to a log file. Which led me to looking for some timeout issue and the same solution you have provided here. However, I have not found it necessary to set the fork count to 0. – Peter

Setting forkcount = 0 is the best solution for me, too. Especially with cached SpringContext in SpringBootTests, which make the tests faster in my case – Zeldazelde

Answer 7

Turn off useSystemClassLoader of maven-surefile-plugin should help

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

Kaiak

This is the one that fixed it for me. I've been building maven via artifactory on a docker image queued from gitlab. It's been difficult to get a representative setup working and after trying a lot of options for surefire settings this one fixed it with version 2.22.0. – Wennerholn

have to add this option for every maven job in Gitlab CI and have no clue why. – Ruche

Answer 8

I faced similar issue after upgrading to java 12, for me the solution was to update jacoco version <jacoco.version>0.8.3</jacoco.version>

Tetrarch

This was indeed the problem I was having with my project. Too bad this answer is not that visible... – Oddfellow

Upgrading the jacoco version to "0.8.7" worked for me. Thanks a lot!! <jacoco-maven-plugin.version>0.8.7</jacoco-maven-plugin.version> – Oversold

Answer 9

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.

Full plugin config:

        <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.

Fourdimensional

This is what worked for me. I am using JUnit and TestNG both for my project (for precisely the same reason), and setting the threadCount helped. – Mcclenon

Answer 10

Was just facing the same problem, java 8 on ubuntu

then came across https://mcmap.net/q/100835/-maven-surefire-could-not-find-forkedbooter-class

It seems a recent bug in the surefire plugin version 2.22.1 with java 8 https://issues.apache.org/jira/browse/SUREFIRE-1588

followed the suggested workaround through local mvn settings ~/.m2/settings.xml

<profiles>
    <profile>
        <id>SUREFIRE-1588</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <argLine>-Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>
        </properties>
    </profile>
</profiles>

Amphipod

A simple add of a more recente version 3.0.0-M1 (for example) have solve the problem. – Moorehead

Answer 11

Using maven surefire 2.21.0 I solved the issue changing the reuseForks option value from true to false:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.21.0</version>
            <configuration>
                <reuseForks>false</reuseForks>
            </configuration>
        </plugin>
    </plugins>
</build>

My whole config section under build looked like:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.21.0</version>
            <configuration>
                <testFailureIgnore>true</testFailureIgnore>
                <skip>false</skip>
                <reuseForks>false</reuseForks>
                <argLine>-Xmx1024m -XX:MaxPermSize=256m</argLine>
                <argLine>-Dfile.encoding=UTF-8</argLine>
                <useSystemClassLoader>false</useSystemClassLoader>
                <includes>
                    <!--Test* classes for the app testing -->
                    <include>**/directory/Test*.java</include>
                </includes>
            </configuration>
        </plugin>
    </plugins>
</build>

Turnaround

Answer 12

version 2.22.2 has real problems with forked JVMs. Use version 2.20 - it works like a charm!

---

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

Dive

Hmm, this actually helps! – Shop

Yeah, v2.22.2 has an issue with maven:3.6-jdk-8-alpine. So annoying! – Forehand

Answer 13

I've met a case when none of the answers provided solved the issue. It was with a legacy application which happens to be using log4j and SLF4J/logback.

The previous situation: clean test builds were running fine when launched from within Eclipse, but when launched in the command line, this error occurred. CI builds on CircleCI ran fine too.

What I did: out of pure guess, is configure a proper logback-test.xml and dial down the verbosity of the logging. Lo and behold, I no longer experienced this error and I can now build the project (as well as the module in which this error was occurring) from the command line.

My point is that the way that the logging frameworks are used or configured may be another explanation.

Was it really a conflict between log4j and logback ? Or was it just that the high volume of logging produced by the tests somehow overflowed a command line buffer? I don't know. It remains a mystery to me.

Femininity

Upvoting because this can really solve/avoid/sidestep the problem. I'm using slf4j and sl4j-simple on Windows and the sluggish output pointed me in this direction too. Setting System.setProperty(SimpleLogger.DEFAULT_LOG_LEVEL_KEY, "warn"); did the trick. Downgrading maven-surefire-plugin to 2.18.1 worked too. – Correy

Answer 14

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.

Koal

Answer 15

I ran into this problem as well in a Jenkins Docker container (tried jenkins:lts, jenkins, jenkins:slim and jenkins:slim-lts. I didn't want to go through all repositories and update the pom for each project, so I just added the disableClassPathURLCheck to the maven command line call:

mvn test -DargLine="-Djdk.net.URLClassPath.disableClassPathURLCheck=true"

Imparadise

Answer 16

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)

Eligibility

Answer 17

This seems to be a thread sync issue on certain Windows machines. If you're having this problem with Windows, try redirecting the output to a file: mvn clean install > output.txt

Ostraw

Do you have a source for this issue? – Hallucinate

It is machine specific. The same repo/branch on another machine won't display the problem. Seriously old, slow and limited machines have more tendency to exhibit this behavior. Large volumes of junit also seem to exhibit this behavior. I can't share one of my repos that shows this as they are in a private and restricted space. If I come across one that is public, I will drop it here. – Ostraw

Thanks, that would be great :) – Hallucinate

Answer 18

I had the same problem with Java 8 and spring boot 5.2.7 (plugin is included, out of the box). The version of the plugin is default (2.22.2). In my case the problems was happening only on some machines in team, while on the other machines everything was fine. I guess it have something to do with the number of cores maven detected.

I fixed it with these settings:

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <configuration>
                <reuseForks>false</reuseForks>
            </configuration>
        </plugin>

I have tried many of the proposed approaches, but nothing was working in my case.

The only downside with this solution is disabling forks' reuse and tests are running slower now.

Verbiage

This doesn't fix the issue – Cassandry

It did fixed issue I had. However, this may not be an universal solution. It seems that same exception is thrown for a number of similar problems. – Satisfied

Well, I don't get the error anymore but my build takes atleast 10 times as long. I solved my issue by removing setting logging.level.root to OFF instead of DEBUG. More specific logging levels are set to debug where they are needed. – Fayina

Answer 19

Solution that worked for me, set: <forkCount>0</forkCount>

i.e.

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

Piranesi

It works, but I don't get why this works. I read the docs, but I don't see why it would not work with forks! – Ensign

Answer 20

you can use below command. Because your unit tests need to fork. That problem about you use thread in your unit test.

mvn test -DforkCount=2

I hope. Its helpful.

Tamaratamarack

this worked in my case – Promiscuous

good i have been happy for you. – Tamaratamarack

Answer 21

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.

Moluccas

Answer 22

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.

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

1.Inside spring boot dependency insert exclusion:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
    <!-- FIX BAMBOO DEPLOY>
    <exclusions>
        <exclusion>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
        </exclusion>
    </exclusions>
    <!---->
</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.

Pomelo

Answer 23

The forked JVM used in the test is running out of memory. The solution would be to either disable forking a JVM and running the tests on the main JVM ensuring you have sufficient memory or to pass args to increase the memory of the forked JVM

Check out the solution in this answer

Orel

Answer 24

I recently had the same problem in an application generated by JHipster 6.10.5 using spring-boot 2.2.7.RELEASE and maven surefire plugin 3.0.0-M4 . It was caused by a timeout due to the extremely long testing log. It was solved by adding the following configuration parameter to maven-surefire-plugin in pom.xml (under pluginManagement):

<forkedProcessExitTimeoutInSeconds>1200</forkedProcessExitTimeoutInSeconds>

See https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkedProcessExitTimeoutInSeconds

Cenis

This solved it for me. Lots of log output in my test. This FAQ indicates that if this timeout kicks in you'll see error message There was a timeout in the fork. I've seen no such message yet it consistently fixes the problem in my case to increase the forkedProcessExitTimeoutInSeconds value. Weird. I'm using surefire-plugin v2.22.2. – Patti

Answer 25

Simple solution: You should add src/test/resources/logback.xml

<configuration debug="false">
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
        <pattern>%date{HH:mm:ss.SSS} %highlight(%-5level)
            %gray(%logger{90}) %X{X-ApplicationId} %msg%n
        </pattern>
    </encoder>
</appender>

Tisdale

Thank you! Turns out it was jacoco crashing my JVM for some reason. – Rancell

Answer 26

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>

Complain

Answer 27

My resolution to this issue was to Close the damn chrome browser which was choking my computer's memory 🙄

Dunno

Answer 28

You can set java options

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

Great

Answer 29

Setting this in pom.xml worked for me. But you should check the documentation for other workarounds https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html

       <plugin>

            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <configuration>
                <!--these strange settings fixes a chrash and dumpstream from surefire when run from command line
                    Caused by: java.lang.ClassNotFoundException: org.apache.maven.surefire.booter.ForkedBooter
                -->
                <useSystemClassLoader>true</useSystemClassLoader>
                <useManifestOnlyJar>false</useManifestOnlyJar>
            </configuration>
        </plugin>

Erikaerikson

Answer 30

tried all above, didn't work. below solution works for me:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19.1</version>
<configuration>
    <argLine>-Dfile.encoding=UTF-8</argLine>
</configuration>

Ferreira

This exact plugin version hepled me. My configuration, by the way, is: Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T21:41:47+03:00) Java version: 1.8.0_201, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.0_201\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" – Winebaum

Answer 31

I had the same issue and solved by using Java 8 from Oracle instead of Java 10 from Openjdk

Disagreeable

Answer 32

I ran into this issue as well on MacOS while remote debugging Selenium test code on port 5005. The problem turned out to be caused by a leftover surefire-forked-JVM that remained running. Log output to the Eclipse IDE terminal did not show the underlying issue which was Address already in use. The log message was only shown when I ran the same command in a MacOS terminal that Eclipse was actually trying to run:

/bin/sh -c cd /path/to/your/project/directory && /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre/bin/java -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 -jar /path/to/target/surefire/surefirebooter230340673926465933.jar /path/to/target/surefire 2019-06-28T10-50-02_140-jvmRun1 surefire6455775580414993159tmp surefire_02461993428448591420tmp

Killing the rogue JVM instance (look for a java process name in Activity Monitor) fixed the issue. By the way I am running the surefire plugin version 2.21.0 with no issues with open jdk 8 (v1.8.0_212). Note that all paths will be specific to your build environment and possibly the port (address=5005).

Lalia

Answer 33

I updated the surefire plugin to the following and this solved my problem:

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

Mannish

Answer 34

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.

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

Glyceric

Answer 35

On Windows (OpenJDK11, Maven 3.6.0, SUREFIRE 3.0.0-M1) I got that root cause:

# Created at 2018-11-14T14:28:15.629
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c7500000, 522190848, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)

and resolved by increasing the paging file size, e.g like this.

Tripetalous

On Linux (4.4.0-145-generic, amd64), changed from Oracle JRE 8 to AdoptOpenJDK_8u202b08 for a Jenkins job and it began producing the "fork" error: - "Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?" - Changed back to Oracle JRE and the error stopped. This is the only job (our of roughly 300) to have this issue. Fortunately it is only an internal project, not a client deliverable co we can keep it on Sun/Oracle JRE. – Swanherd

Answer 36

I tried all the provided solutions (forking, systemloader, more memory etc..), nothing worked.

Environment: The build failed in gitlab ci environment, running the build inside a docker container.

Solution: We used surefireplugin in version 2.20.1 and upgrading to 2.21.0 or greater (we used 2.22.1) fixed the issue.

Cause: SUREFIRE-1422 - surefire uses the command ps, which wasnt available in the docker environment and led to the "crash". This issue is fixed in 2.21.0 or greater.

Thanks to this answer from another question: https://mcmap.net/q/100837/-docker-gt-maven-gt-failsafe-gt-surefire-starting-fork-fails-with-quot-the-forked-vm-terminated-without-properly-saying-goodbye-vm-crash-or-system-exit-called-quot

Heptahedron

Answer 37

I had a situation similar to Chad's, but found a different answer.

Per the plugin docs, you can't use ${...} in <argLine> because Maven will pick that up for replacement before the surefire plugin (or any other plugin) does.

Since version 2.17, the plugin supports @{...} instead of ${...} for property replacement.

So for example, replace this

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

with this

<argLine>XX:MaxPermSize=1024m @{moreArgs}</argLine>

Terce

Answer 38

I was facing the same issue when running unit tests using maven test . Tried changing the surefire versions but it dinnt work. Finally managed to solve as follows: EARLIER: (when the issue was happening): javac is from jdk 1.8 java was pointing to the java bin from jdk 1.11 CURRENT: (when the issue got resolved): both javac & java are pointing to the bins from jdk 1.8

Regards Teja .

Chancy

Answer 39

this error I was able to remove after adding profile:

<profile>
            <id>surefire-windows-fork-disable</id>
            <activation>
                <os>
                    <family>Windows</family>
                </os>
            </activation>
            <build>
                <pluginManagement>
                    <plugins>
                        <plugin>
                            <groupId>org.apache.maven.plugins</groupId>
                            <artifactId>maven-surefire-plugin</artifactId>
                            <configuration>
                                <forkCount>0</forkCount>
                                <useSystemClassLoader>false</useSystemClassLoader>
                            </configuration>
                        </plugin>
                    </plugins>
                </pluginManagement>
            </build>
        </profile>

seems that this is a windows problem regarding maven surefire forks

Anguiano

Answer 40

It hapenned to me at some point after dozens of Maven runs in debug mode:

-Dmaven.surefire.debug="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005"

I had to kill extra java processes that were still running for some reasons in parallel.

Novelette

Answer 41

If you are running sonar build by clean verify sonar:sonar and some of the file that generating lots of logs, that logs is issuing this vm termination.

To solve this issue you can follow below steps.

1. In the test resources, add logback-test.xml.

2. Change the log level to INFO mode.

3. in maven-surefire-plugin add below configuration.

   <configuration>
      <reuseForks>false</reuseForks>
      <forkCount>1</forkCount>
   </configuration>
   

Now the INFO log will be generated and vm will not crash.

Genitor

Answer 42

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.

Rabbitry

Answer 43

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.

Inhabit

Was that on a windows machine? – Folkestone

Yes, it is running in Windows . – Inhabit

How did you found that? – Dorice

Answer 44

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
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.

Doradorado

Answer 45

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)

Disharoon

Answer 46

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.

Reprobative

Answer 47

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)).

1. Using a simple return statement instead helps.

2. 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)

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

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

Delegate

Answer 48

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.

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.

Nard

Answer 49

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.

Eldrid

Answer 50

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>

Inset

Answer 51

For my case, it was my code calling System.exit(0).

Here is the extract about it from te documentation:

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.

Some

Answer 52

In my case increasing mem by setting MAVEN_OPTS helped:

set MAVEN_OPTS=-Xmx1024m

Illustrative

Answer 53

I was using folder name As test&demo so it was giving this problem (VM terminated without saying properly goodbye. VM crash or System.exit called),but When i gave folder name as test_demo then it solved this issue.(this problem is there with windows OS with "&" symbol.)

Replace "&" to "_"

This problem may cause with some special symbol or extra space in folder name.

Employee

Answer 54

I had the same problem in an app that was logging lots of XML to the console whilst it was running tests. I think the issue is something to do with the way the test fork sends its console logging to the main maven thread to be output to the screen.

I worked around the issue by setting the logging of the offending class to WARN in my test logback file.

Eg logback-test.xml

<configuration debug="true">
  <include resource="org/springframework/boot/logging/logback/defaults.xml" />
  <include resource="org/springframework/boot/logging/logback/console-appender.xml" />

  <logger name="com.foo.ClassWithLotsOfXmlLogging" level="WARN" />

  <root level="INFO">
    <appender-ref ref="CONSOLE"/>
  </root>
</configuration>

Cartage

Answer 55

I had this many time, and for me, this is almost always "console" related and has nothing to do with actual forking.

In short, my solution is :

• Add -B (batch mode)
• Add JVM args -Djansi.force=true -Djansi.passthrough=true

On a given project this would fails systematically in a new windows console (cmd.exe)

[path_to_jdk]\java.exe -Dmaven.home=[path_to_maven]\apache-maven-3.6.3 -Dclassworlds.conf=[path_to_maven]\bin..\bin\m2.conf -Dmaven.multiModuleProjectDirectory=[path_to_myproject] -Dfile.encoding=UTF-8 -Djansi.force=true -Djansi.passthrough=true -classpath [path_to_maven]\boot\plexus-classworlds-2.6.0.jar org.codehaus.plexus.classworlds.launcher.Launcher clean install -B

This will always works in a new console window (cmd.exe).

[path_to_jdk]\java.exe -Dmaven.home=[path_to_maven]\apache-maven-3.6.3 -Dclassworlds.conf=[path_to_maven]\bin..\bin\m2.conf -Dmaven.multiModuleProjectDirectory=[path_to_myproject] -Dfile.encoding=UTF-8 -Djansi.force=true -Djansi.passthrough=true -classpath [path_to_maven]\boot\plexus-classworlds-2.6.0.jar org.codehaus.plexus.classworlds.launcher.Launcher clean install -B

Notice that both command have -B (batch mode which should turn off coloring), and the only difference is

-Djansi.force=true -Djansi.passthrough=true

Now I just need to be able to pass these "JVM args" the the "mvn.cmd" to make this better.

Something like this I guess : Is there a way to pass jvm args via command line to maven?

---

A bit of background :

I had this problem repeatedly since the latest versions of maven (3.x +). I have tried many of the solutions here, sometimes with luck, sometimes not.

This article from the official doc has always been useless : https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html

But there are constants, when I ran in this problem :

• Always on windows, locally
• Always LOTS of console output.
• Not all dev of the team getting the error on a given project
• Jenkins build would pass
• LOTS of console output in *IT test (failsafe integration tests)

The key discovery was that I noticed that within Eclipse, (with or without the embedded maven version) a ful maven build (clean install) would work.

So I figured out which command Eclipse was using (thanks : How do I get the command-line for an Eclipse run configuration?)

From there, I was able to determine was the solution was.

See other answer where people are saying

• output to logfile
• reduce log level
• https://mcmap.net/q/98632/-the-forked-vm-terminated-without-saying-properly-goodbye-vm-crash-or-system-exit-called
• https://mcmap.net/q/98632/-the-forked-vm-terminated-without-saying-properly-goodbye-vm-crash-or-system-exit-called
• etc

There is clearly a bug there. Either in Maven or in the windows console, or in the Jansi lib, or in the integration of these components.

Matteroffact

Answer 56

Happened to me: if your project depends on docker machine or/ and database to build successfully then please check first that your db instance is up and your docker is also up because maybe there are some unit tests running in the background ... check that especially after starting your laptop.. hope that could help someone

Intitule

Answer 57

my resolution was to change the timeout mentioned in Jenkinsfile from 90 to 120.

pipeline {
    agent { label projectName }

options {
    disableConcurrentBuilds()
    buildDiscarder(logRotator(numToKeepStr:'5'))
    timeout(time: 90, unit: 'MINUTES')
}

Thanks, SA

Contralto

Answer 58

This worked for me.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M5</version>
<configuration>
    <argLine>-Dfile.encoding=UTF-8</argLine>
</configuration>
</plugin>

Militarism

Answer 59

I had the same problem while after updating Maven from 2.6.3 to 2.8.4. The problem was that forked JVM crushed by out of memory, so just increased memory from 1024Mb to 2048Mb in Surefire plugin config and that solved the issue

        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <configuration>
                <!--suppress UnresolvedMavenProperty -->
                <argLine>${argLine} -Dfile.encoding=UTF-8 -Xmx2048m</argLine>
            </configuration>
        </plugin>

Jolee

Answer 60

I forgot to declare maven-surefire in my Java 7 project's pom.xml, so it defaulted to use the Java 8 version in maven's runtime. (i thought it was declared in a parent)

Adding surefire to the build section in the pom solved the problem.

<build>
    <plugins>
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.12</version>
            <configuration>
                <argLine>-XX:-UseSplitVerifier</argLine>
                <skip>${maven.skip}</skip>
                <skipTests>${maven.skipTests}</skipTests>
             </configuration>
         </plugin>
    </plugins>
</build>

Cassock

Answer 61

I tried many of the solutions described here. None solved the problem. Eventually, the only thing that helped was an upgrade of maven itself from v3.6.1 to v3.8.6. (I used corretto jdk11.0.12_7 for the build)

Stavanger

Answer 62

I tried updating sure-fire plug-in configurations as well as updating maven settings.xml. It did not work for me. Finally tried exporting the console output to the .txt file and issue got resolved.

Outport

Answer 63

In my case, I used javaagent in integration tests. I found that javaagent wasn't downloaded and this led to such error. So ensure your application can access javaagent.

Newcomer

Answer 64

What fixed it for me was to add to both surefire and failsafe plugins the following configuration:

<configuration>
   <reuseForks>false</reuseForks>
   <forkCount>0</forkCount>
</configuration>

Nadinenadir

Answer 65

Your java version is not compatible with this project . Please downgrade you java version from the system and set the path and run the project. i hope it would resolved the issue.

best if luck!!

Favourite

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Lialiabilities

Answer 66

Found a new solution for 2024. My Project is Spring-Boot 3.x, Java 17:

Problem

Error Log:

...
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.2.5:test (default-test) on project rest-clients: 
[ERROR] 
[ERROR] Please refer to /rest-clients/target/surefire-reports for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] ExecutionException Error occurred in starting fork, check output in log
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: ExecutionException Error occurred in starting fork, check output in log
[ERROR]         at org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:456)
[ERROR]         at org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:358)
[ERROR]         at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:296)
[ERROR]         at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:250)
[ERROR]         at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1241)
[ERROR]         at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1090)
[ERROR]         at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:910)
[ERROR]         at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR]         at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:370)
[ERROR]         at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:351)
[ERROR]         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:215)
[ERROR]         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:171)
[ERROR]         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:163)
[ERROR]         at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR]         at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR]         at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR]         at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR]         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:294)
[ERROR]         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR]         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR]         at org.apache.maven.cli.MavenCli.execute(MavenCli.java:960)
[ERROR]         at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:293)
[ERROR]         at org.apache.maven.cli.MavenCli.main(MavenCli.java:196)
[ERROR]         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
[ERROR]         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
[ERROR]         at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
[ERROR]         at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
[ERROR]         at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
[ERROR]         at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
[ERROR]         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
[ERROR]         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
[ERROR]         at org.apache.maven.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:52)
[ERROR]         at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:161)
[ERROR]         at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:73)
[ERROR] Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: Error occurred in starting fork, check output in log
[ERROR]         at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:577)
[ERROR]         at org.apache.maven.plugin.surefire.booterclient.ForkStarter.lambda$null$3(ForkStarter.java:350)
[ERROR]         at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
[ERROR]         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
[ERROR]         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
[ERROR]         at java.base/java.lang.Thread.run(Thread.java:1583)
[ERROR] 
[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/MojoExecutionException

I had a Spring-Boot Test that took a long time to shut down gracefully. My Tests are written using the Spock Framework.

Solution

The config which worked for me was surefire config property shutdown. When you use value testset, the docs say: "With(shutdown=testset) the test set may still continue to run in forked JVM."

My understanding this changes the default 'force kill' forks behavior to a synchronous 'wait for test set to exit on it's own' behavior.

So I used this property to remove the error, so far successfully when running the maven commands from within IntelliJ IDEA, MacOS Terminal (ZSH), or Jenkins SH step.

I'm using the following plugin version properties & plugin configs in my pom.xml to execute Spring-Boot Tests written with the Spock Framework and the jacoco-maven-plugin to generate a test coverage report.

pom.xml

<properties>
  <maven-surefire-plugin.version>3.2.5</maven-surefire-plugin.version><!-- Check the latest version: https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-surefire-plugin -->
  <gmavenplus-plugin.version>3.0.2</gmavenplus-plugin.version><!-- Check the latest version: https://mvnrepository.com/artifact/org.codehaus.gmavenplus/gmavenplus-plugin -->
  <jacoco-maven-plugin.version>0.8.11</jacoco-maven-plugin.version><!-- Check the latest version: https://mvnrepository.com/artifact/org.jacoco/jacoco-maven-plugin -->
</properties>

<build>
  <plugins>
    <!-- Test Plugins :: Start -->
    <plugin>
      <groupId>org.codehaus.gmavenplus</groupId>
      <artifactId>gmavenplus-plugin</artifactId>
      <version>${gmavenplus-plugin.version}</version>
      <executions>
        <execution>
          <goals>
            <goal>addTestSources</goal>
            <goal>compileTests</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>${maven-surefire-plugin.version}</version>
      <configuration>
        <parallel>classes</parallel>
        <threadCount>4</threadCount>
        <forkCount>2</forkCount>
        <!-- jacoco-maven-plugin :: When using the maven-surefire-plugin or maven-failsafe-plugin you must not use
             a `forkCount` of `0` or set the `forkMode` to `never` as this would prevent the execution of the tests
             with the javaagent set and no coverage would be recorded.
             @see https://www.jacoco.org/jacoco/trunk/doc/maven.html
        -->
        <!-- After the plugin process is shutdown by sending SIGTERM signal (CTRL+C), SHUTDOWN command is received by
           every forked JVM. The value is set to (shutdown=exit) by default (changed in version 3.0.0-M4). The
           parameter can be configured with other two values testset and kill. With(shutdown=testset) the test set
           may still continue to run in forked JVM. Using exit forked JVM executes System.exit(1) after the plugin
           process has received SIGTERM signal.
           Maven Docs: https://maven.apache.org/surefire/maven-surefire-plugin/examples/shutdown.html
           StackOverflow: 
        -->
        <shutdown>testset</shutdown>
        <!--suppress UnresolvedMavenProperty -->
        <argLine>${maven-surefire-plugin.jvm-flags} ${argLine}</argLine>
        <includes>
          <include>**/*Spec.java</include>
          <include>**/*Test.java</include>
        </includes>
      </configuration>
    </plugin>
    <plugin>
      <groupId>org.jacoco</groupId>
      <artifactId>jacoco-maven-plugin</artifactId>
      <version>${jacoco-maven-plugin.version}</version>
      <executions>
        <execution>
          <id>jacoco-initialize</id>
          <phase>process-test-classes</phase><!-- https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference -->
          <goals>
            <goal>prepare-agent</goal>
          </goals>
        </execution>
        <execution>
          <id>jacoco-report</id>
          <phase>test</phase><!-- https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference -->
          <goals>
            <goal>report</goal>
          </goals>
        </execution>
        <execution>
          <id>jacoco-check</id>
          <phase>test</phase><!-- https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference -->
          <goals>
            <goal>check</goal>
          </goals>
          <configuration>
            <haltOnFailure>false</haltOnFailure><!-- https://www.jacoco.org/jacoco/trunk/doc/check-mojo.html#haltOnFailure -->
            <rules>
              <rule>
                <element>PACKAGE</element>
                <limits>
                  <limit>
                    <counter>METHOD</counter>
                    <value>COVEREDRATIO</value>
                    <minimum>80%</minimum>
                  </limit>
                  <limit>
                    <counter>CLASS</counter>
                    <value>MISSEDCOUNT</value>
                    <maximum>0</maximum>
                  </limit>
                </limits>
              </rule>
            </rules>
          </configuration>
        </execution>
      </executions>
    </plugin>
    <!-- Test Plugins :: End -->
  </plugins>
</build>

Hardiman

According to your link it is default parameter value: By default (configuration parameter shutdown=testset). My guess is your builds was stabilized by other configurations. – Robbierobbin

Answer 67

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.

Strictly

Answer 68

"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.

Appendix

Answer 69

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.

Provoke

Answer 70

for me it worked with

mvn clean install -DskipTests -e

Federalize

Skipping tests is a way to sweep problem under the rug, not fix it. – Standpipe

I love his thinking :). Made my day. – Constructivism