CODEWITHSUNDEEP
javamaven-surefire-pluginopendaylight
astack
astack

Reputation: 4047

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

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

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 21.749s
[INFO] Finished at: Thu Apr 24 10:10:20 IST 2014
[INFO] Final Memory: 15M/37M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on project samples.simpleforwarding: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
[ERROR] Command wascmd.exe /X /C ""C:\Program 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

Upvotes: 334

Views: 426077

Answers (30)

Saša
Saša

Reputation: 4818

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 were 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 is causing the tests to run slower now.

Upvotes: 7

Yagoub GRINE
Yagoub GRINE

Reputation: 65

If you’re using IntelliJ IDEA, you can resolve this issue by adding the following parameters to your Maven test lifecycle configuration:

MAVEN_OPTS=-Xms512m -Xmx1024m -XX:MaxPermSize=1024m

Steps to Apply:

  1. Open your Maven tool window in IntelliJ IDEA.

  2. Right-click on the test lifecycle phase and select Edit Configuration.

  3. In the dialog that appears: • Under Java Options, uncheck the “Inherit from settings” box if needed. • Add the environment variable MAVEN_OPTS with the value: -Xms512m -Xmx1024m -XX:MaxPermSize=1024m 4. Click Apply and OK.

Here are the relevant screenshots for reference:

  1. Accessing the Maven Lifecycle Test Accessing the Maven Lifecycle Test
  2. Configuring Maven Options in IntelliJ: Configuring Maven Options in IntelliJ

Upvotes: 0

peterh
peterh

Reputation: 19285

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. See below under "forkCount solution".
  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. See below under "forkedProcessExitTimeoutInSeconds solution".

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.

forkCount solution:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <forkCount>0</forkCount> 
  </configuration>
</plugin>

forkedProcessExitTimeoutInSeconds solution:

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

Upvotes: 33

ranma2913
ranma2913

Reputation: 1206

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>

Upvotes: 0

raj bhandari
raj bhandari

Reputation: 1

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

Upvotes: 0

dehidehidehi
dehidehidehi

Reputation: 117

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>

Upvotes: 0

Valeriy K.
Valeriy K.

Reputation: 2904

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.

Upvotes: 0

TechieAmol
TechieAmol

Reputation: 1

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.

Upvotes: 0

Suraj
Suraj

Reputation: 3137

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.

Upvotes: 1

Boomer
Boomer

Reputation: 3721

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)

Upvotes: 0

Adrian C
Adrian C

Reputation: 101

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>

Upvotes: 0

vitali_li
vitali_li

Reputation: 130

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.

Upvotes: 1

Javasick
Javasick

Reputation: 3003

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>

Upvotes: 0

cdc
cdc

Reputation: 2571

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>

Upvotes: 7

Abhimanu Rana
Abhimanu Rana

Reputation: 1

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>

Upvotes: 0

Sindhu
Sindhu

Reputation: 1

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

Upvotes: 0

salihgungor
salihgungor

Reputation: 111

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.

Upvotes: 5

m.irouch
m.irouch

Reputation: 61

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

Upvotes: 0

fillumina
fillumina

Reputation: 93

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

Upvotes: 4

Никита Верёвкин
Никита Верёвкин

Reputation: 91

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>

Upvotes: 3

Filip
Filip

Reputation: 1068

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

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.

Upvotes: 0

Loi Cao
Loi Cao

Reputation: 503

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>

Upvotes: 16

ugurkocak1980
ugurkocak1980

Reputation: 152

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

Upvotes: 1

lance-java
lance-java

Reputation: 28016

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>

Upvotes: 0

Scott Lindner
Scott Lindner

Reputation: 584

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

Upvotes: 6

Arefe
Arefe

Reputation: 12441

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>

Upvotes: 2

teja
teja

Reputation: 21

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 .

Upvotes: 1

RANDHIR KUMAR
RANDHIR KUMAR

Reputation: 1

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.

Upvotes: 0

Alex
Alex

Reputation: 627

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>

Upvotes: 9

SOLO
SOLO

Reputation: 868

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>

Upvotes: 1

Related Questions