-->

The forked VM terminated without saying properly g

2020-01-24 03:50发布

问题:

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

回答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>


回答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


回答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>


回答4:

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://stackoverflow.com/a/50661649/1228408


回答5:

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.



回答6:

Was just facing the same problem, java 8 on ubuntu

then came across https://stackoverflow.com/a/53016532/1676516

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>


回答7:

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.



回答8:

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)



回答9:

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>


回答10:

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.



回答11:

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"


回答12:

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.



回答13:

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.



回答14:

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.



回答15:

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>


回答16:

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>


回答17:

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>



回答18:

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.



回答19:

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