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
This question is related to
java
maven-surefire-plugin
opendaylight
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.
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:
maven:3.5.4-jdk-8 to maven:3.5.4-jdk-8-alpineI 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.
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)
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>
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>
My resolution to this issue was to Close the damn chrome browser which was choking my computer's memory
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://stackoverflow.com/a/50568662/2970422
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.
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
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"
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>
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.
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.
I had the same issue and solved by using Java 8 from Oracle instead of Java 10 from Openjdk
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)
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 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>
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>
for me it worked with
mvn clean install -DskipTests -e
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>
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 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 faced similar issue after upgrading to java 12, for me the solution was to update jacoco version <jacoco.version>0.8.3</jacoco.version>
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.
I am still working on making this fix in our builds, will come back and update the thread again.
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.
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.
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>
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
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>
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.
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.
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>
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.
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>
You can set java options
SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate
mvn clean install
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
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
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.
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.
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)).
Using a simple return statement instead helps.
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.
In my case increasing mem by setting MAVEN_OPTS helped:
set MAVEN_OPTS=-Xmx1024m
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>
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).
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>
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.
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.
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.
<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.
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.
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 .
Source: Stackoverflow.com