A VM bifurcada terminou sem se despedir adequadamente. Falha na VM ou System.exit chamado

Por favor, me ajude a resolver essa questão. Não entendo exatamente o que significa o erro no log.

[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

Eu tive o mesmo problema e resolvi adicionando:

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

Todo o elemento do plugin é:

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

No meu caso, o problema estava relacionado à saída de log muito longa no console do IntelliJ IDEA (SO Windows 10).

Comando:

mvn clean install

Este comando resolveu o problema para mim:

mvn clean install > log-file.log

Eu tenho um problema muito semelhante ( compilação do Maven e maven-failafe-plugin - a VM bifurcada foi encerrada sem se despedir corretamente ) e encontrou três soluções que funcionavam para mim:

Descrição do Problema

O problema está no plugin maven maven-surefire-plugin apenas na versão 2.20.1 e 2.21.0. Eu verifiquei e você usa a versão 2.20.1.

Solução 1

Atualize a versão do plugin para 2.22.0 . Adicione pom.xml :

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

Solução 2

Faça o downgrade da versão do plugin para 2.20 . Adicione pom.xml :

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

Solução 3

Use a configuração de plug-in testFailureIgnore . Adicione pom.xml :

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

A partir de hoje (30/10/2018), notamos que nossas compilações foram interrompidas em Jenkins com esse erro.

O erro é um pouco enganador e é necessário examinar a saída do despejo target/surefire-reports/ para ver a seguinte mensagem de erro:

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

Isso me levou à seguinte postagem do SO, que menciona um possível bug no OpenJDK 181: Maven surefire não pôde encontrar a classe ForkedBooter

Qualquer uma das correções nessa postagem resolve meu problema. Para ser específico, usei um destes:

1. Mudando de construção no contêiner de docker maven:3.5.4-jdk-8paramaven:3.5.4-jdk-8-alpine
2. Substituindo o carregador de classes do Spring Boot detalhado aqui: https://stackoverflow.com/a/50661649/1228408

Esta parte das Perguntas frequentes do Surefire pode ajudá-lo:

O Surefire falha com a mensagem "A VM bifurcada terminou sem se despedir corretamente"

O Surefire não suporta testes ou bibliotecas referenciadas que chamam System.exit () a qualquer momento. Se o fizerem, serão incompatíveis com o surefire e você provavelmente deverá registrar um problema na biblioteca / fornecedor. Como alternativa, a VM bifurcada também pode falhar por vários motivos, o que também pode causar esse problema. Procure os arquivos "hs_err *" clássicos que indicam falhas na VM ou examine a saída de log da execução do maven quando os testes forem executados. Algumas saídas "extraordinárias" de processos com falha podem ser despejadas no console / log. Se isso acontecer em um ambiente de IC e somente após algum tempo, é provável que seu conjunto de testes esteja vazando algum tipo de recurso no nível do sistema operacional que piora as coisas a cada execução. Ferramentas regulares de monitoramento no nível do sistema operacional podem fornecer algumas indicações.

Estava apenas enfrentando o mesmo problema, java 8 no ubuntu

então deparei com https://stackoverflow.com/a/53016532/1676516

Parece um bug recente na versão do plugin surefire 2.22.1 com java 8 https://issues.apache.org/jira/browse/SUREFIRE-1588

seguiu a solução sugerida através das configurações locais de MVN ~/.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>

Hoje tive o mesmo problema e, para mim, o problema real foi relatado mais adiante no log com a mensagem Cannot use a threadCount parameter less than 1; 1 > 0. Ao adicionar <threadCount>1</threadCount>a configuração do surefire-plugin, o outro erro desapareceu.

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

... e sim, estou usando junit e testng nesta estrutura de teste por motivos de compatibilidade com versões anteriores.

Teve um problema semelhante ao executar o comando mvn com o plugin Jacoco no 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?

Houve um erro no JDK https://bugs.openjdk.java.net/browse/JDK-8081379

E a solução era executar o mvn clean install com o parâmetro -XX: -UseLoopPredicate

Ou apenas faça uma atualização no JDK (acho que a versão menor mais recente funciona)

Desativar useSystemClassLoader do maven-surefile-plugin

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

Se alguém estiver incluindo um argumento argLine personalizado, você deve reconsiderar, porque provavelmente é a fonte dos seus problemas com a alocação de memória.

Por exemplo (eu costumava ter):

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

Agora eu uso valores rígidos especificados:

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

Por qualquer motivo, os aplicativos que se integram ao Surefire, como o Jacoco, não solicitam memória suficiente para coexistir com os testes que ocorrem no momento da construção.

Também deparei com esse problema em um contêiner Jenkins Docker (tentei jenkins: lts, ​​jenkins, jenkins: slim e jenkins: slim-lts. Eu não queria passar por todos os repositórios e atualizar o pom para cada projeto, então eu acabou de adicionar o disableClassPathURLCheck à chamada da linha de comando maven:

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

Usando o maven surefire 2.21.0, resolvi o problema alterando o reuseForksvalor da opção de true para 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>

Toda a minha seção de configuração em build parecia:

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

Você precisa verificar se sua máquina é de 64 bits ou 32 bits. Se sua máquina tiver 32 bits, seu argumento de memória não deverá exceder 4096, mesmo que seja inferior a 4 GB. mas se sua máquina for de 64 bits, instale o Java de 64 bits e forneça JAVA_HOME no mvn.bat, que aponta para a instalação em java de 64 bits.

Encontrei um caso em que nenhuma das respostas fornecidas resolveu o problema. Foi com um aplicativo herdado que está usando log4j e SLF4J / logback.

A situação anterior: as clean testconstruções estavam funcionando bem quando ativadas a partir do Eclipse, mas quando ativadas na linha de comandos, ocorreu este erro. O CI baseia-se no CircleCI também correu bem.

O que eu fiz: por pura suposição, é configurar um apropriado logback-test.xmle discar a verbosidade do log. Eis que já não tive esse erro e agora posso criar o projeto (assim como o módulo no qual esse erro estava ocorrendo) a partir da linha de comando.

Meu argumento é que a maneira como as estruturas de log são usadas ou configuradas pode ser outra explicação .

Foi realmente um conflito entre log4j e logback? Ou foi apenas que o alto volume de registro produzido pelos testes de alguma forma transbordou um buffer da linha de comando? Eu não sei. Continua sendo um mistério para mim.

Enfrentei um problema semelhante após atualizar para o java 12, para mim a solução foi atualizar a versão jacoco <jacoco.version>0.8.3</jacoco.version>

a versão 2.22.2 tem problemas reais com JVMs bifurcadas. Use a versão 2.20 - funciona como um encanto!

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

Recentemente, fiquei com esse erro ao criar meus aplicativos jar em contêiner com o Bamboo:

org.apache.maven.surefire.booter.SurefireBooterForkException: A VM bifurcada foi encerrada sem se despedir adequadamente

Depois de muitas horas pesquisando, eu o consertei. E achei que seria útil compartilhar minha solução aqui.

Portanto, o erro ocorre sempre que o mvn clean packagecomando de execução de bambu para aplicativos java nos contêineres do docker. Eu não sou especialista em Maven, mas o problema estava nos plugins Surefire e Junit4 incluídos no boot como mola.

Para corrigi-lo, você precisa substituir o Junit4 por Junit5 e substituir o plug-in Surefire em você pom.xml.

Exclusão interna da inserção da dependência da bota de mola:

<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. Adicione novas dependências do Junit5:

<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. Insira um novo plugin na seção de plugins

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

Isso deve ser suficiente para reparar construções de bambu. Não esqueça também de transformar todos os testes do Junit4 para dar suporte ao Junit5.

Definir isso no pom.xml funcionou para mim. Mas você deve verificar a documentação para outras soluções alternativas, 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>

A JVM bifurcada usada no teste está ficando sem memória. A solução seria desativar a bifurcação de uma JVM e executar os testes na JVM principal, garantindo que você tenha memória suficiente ou passar argumentos para aumentar a memória da JVM bifurcada

Confira a solução nesta resposta

Eu me deparei com esse problema durante o Jenkins construir em uma máquina Ubuntu.

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

Portanto, dei à máquina Ubuntu mais espaço de troca . Desde então, o problema se foi.

Minha resolução para esse problema foi fechar o maldito navegador chrome que estava sufocando a memória do meu computador 🙄

Você pode definir opções de java

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

No Windows (OpenJDK11, Maven 3.6.0, SUREFIRE 3.0.0-M1), obtive essa causa raiz:

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

e resolvido aumentando o tamanho do arquivo de paginação, por exemplo, como este .

tentei tudo acima, não funcionou. a solução abaixo funciona para mim:

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

Eu tive o mesmo problema e resolvi usando o Java 8 do Oracle em vez do Java 10 do Openjdk

Eu tentei todas as soluções fornecidas (bifurcação, carregador de sistema, mais memória etc.), nada funcionou.

Meio Ambiente : a construção falhou no ambiente do gitlab ci, executando a construção dentro de um contêiner de janela de encaixe.

Solução : usamos o surefireplugin na versão 2.20.1 e a atualização para 2.21.0 ou superior (usamos o 2.22.1) corrigiu o problema.

Causa : SUREFIRE-1422 - surefire usa o comandops , que não estava disponível no ambiente do docker e levou ao "travamento". Esse problema foi corrigido na 2.21.0 ou superior.

Graças a esta resposta de outra pergunta: https://stackoverflow.com/a/50568662/2970422

Também deparei com esse problema no MacOS durante a depuração remota do código de teste Selenium na porta 5005. O problema acabou sendo causado por uma JVM restante com segurança bifurcada que permanecia em execução. A saída de log para o terminal IDE do Eclipse não mostrou o problema subjacente que era o Endereço já em uso . A mensagem de log foi mostrada apenas quando executei o mesmo comando em um terminal MacOS que o Eclipse estava realmente tentando executar:

/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

A morte da instância desonesta da JVM (procure um nome de processo java no Activity Monitor) corrigiu o problema. A propósito, estou executando a versão 2.21.0 do plugin surefire sem problemas com o jdk 8 aberto (v1.8.0_212). Observe que todos os caminhos serão específicos para o seu ambiente de construção e, possivelmente, a porta (endereço = 5005).

Eu estava enfrentando o mesmo problema ao executar testes de unidade usando o teste maven. Tentei mudar as versões infalíveis, mas não funcionou. Finalmente consegui resolver o seguinte: EARLIER: (quando o problema estava acontecendo): javac é do jdk 1.8 java estava apontando para o java bin do jdk 1.11 ATUAL: (quando o problema foi resolvido): javac e java estão apontando para o caixas de jdk 1.8

Atenciosamente Teja.

Eu experimentei esse erro depois que uma variável de membro estática na minha classe de teste chamou um método para criar um objeto (que foi usado em casos de teste em toda a classe), e o método causou uma exceção.

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

Algumas correções incluem a recriação do objeto dentro de cada caso de teste e a captura de exceções de acordo. Ou inicializando o objeto dentro de um método @BeforeTest e assegurando que ele seja criado corretamente.

No meu caso, o problema estava relacionado ao caminho do espaço de trabalho que era muito longo. Então, refatorei o caminho e isso resolveu o problema para mim.