La VM bifurcada terminó sin decir adiós correctamente. VM crash o System.exit llamado

Porfavor ayudame a resolver este problema. No entiendo exactamente qué significa el error en el registro.

[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

Tuve el mismo problema y lo resolví agregando:

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

Todo el elemento del complemento es:

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

En mi caso, el problema estaba relacionado con la salida de registros demasiado larga en la consola IntelliJ IDEA (sistema operativo Windows 10).

Mando:

mvn clean install

Este comando me resolvió el problema:

mvn clean install > log-file.log

Tengo un problema muy similar ( Maven build y maven-failsafe-plugin - La VM bifurcada finalizó sin decir adiós correctamente ) y encontré tres soluciones que funcionaron para mí:

Descripción del problema

El problema es que con Maven plugin de maven-segura-plugin sólo en la versión 2.20.1 y 2.21.0. Lo comprobé y usas la versión 2.20.1.

Solución 1

Actualice la versión del complemento a 2.22.0 . Añadir en pom.xml :

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

Solución 2

Versión de plugin downgrade a 2.20 . Añadir en pom.xml :

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

Solución 3

Use la prueba de configuración del complemento TestFailureIgnore . Añadir en pom.xml :

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

A partir de hoy (30/10/2018), notamos que nuestras compilaciones se rompían en Jenkins con este error.

El error es un poco engañoso y requiere mirar la salida del volcado target/surefire-reports/ para ver el siguiente mensaje de error:

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

Eso me llevó a la siguiente publicación SO que menciona un posible error en OpenJDK 181: Maven surefire no pudo encontrar la clase ForkedBooter

Cualquiera de las correcciones en esa publicación resuelve mi problema. Para ser específico, utilicé cualquiera de estos:

1. Cambiar de edificio en el contenedor acoplable maven:3.5.4-jdk-8amaven:3.5.4-jdk-8-alpine
2. Anulando el cargador de clases de Spring Boot detallado aquí: https://stackoverflow.com/a/50661649/1228408

Esta parte de las preguntas frecuentes de Surefire podría ayudarlo a:

Surefire falla con el mensaje "La VM bifurcada finalizó sin decir adiós correctamente"

Surefire no admite pruebas ni ninguna biblioteca referenciada que llame a System.exit () en ningún momento. Si lo hacen, son incompatibles con surefire y probablemente debería presentar un problema con la biblioteca / proveedor. Alternativamente, la VM bifurcada también podría fallar por varias razones, que también pueden hacer que este problema suceda. Busque los archivos clásicos "hs_err *" que indican fallas de VM o examine la salida del registro de ejecutar maven cuando se ejecutan las pruebas. Parte de la salida "extraordinaria" de los procesos de bloqueo puede volcarse a la consola / registro. Si esto sucede en un entorno de CI y solo después de un tiempo de ejecución, existe la posibilidad de que su conjunto de pruebas pierda algún tipo de recurso a nivel del sistema operativo que empeora las cosas en cada ejecución. Las herramientas regulares de monitoreo de nivel os pueden darle alguna indicación.

Estaba enfrentando el mismo problema, java 8 en ubuntu

luego encontré https://stackoverflow.com/a/53016532/1676516

Parece un error reciente en la versión 2.22.1 del complemento surefire con java 8 https://issues.apache.org/jira/browse/SUREFIRE-1588

siguió la solución sugerida a través de la configuración local 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>

Tuve el mismo problema hoy y para mí el problema real se informó más arriba en el registro con el mensaje Cannot use a threadCount parameter less than 1; 1 > 0. Al agregar <threadCount>1</threadCount>la configuración surefire-plugin, el otro error desapareció.

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

... y sí, estoy usando junit y testng en este marco de prueba por razones de compatibilidad con versiones anteriores.

Tuve un problema similar al ejecutar el comando mvn con el complemento Jacoco en 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?

Hubo un error en JDK https://bugs.openjdk.java.net/browse/JDK-8081379

Y la solución fue ejecutar mvn clean install con param -XX: -UseLoopPredicate

O simplemente haga una actualización a JDK (creo que la versión menor más nueva funciona)

Desactivar useSystemClassLoader de maven-surefile-plugin debería ayudar

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

Si alguien incluye un argumento argLine personalizado, debe reconsiderarlo porque probablemente sea la fuente de sus problemas con la asignación de memoria.

Por ejemplo (solía tener):

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

Ahora uso valores especificados estrictamente:

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

Por alguna razón, las aplicaciones que se integran con Surefire, como Jacoco, no solicitan suficiente memoria para coexistir con las pruebas que ocurren en el momento de la compilación.

También me encontré con este problema en un contenedor Jenkins Docker (probé jenkins: lts, ​​jenkins, jenkins: slim y jenkins: slim-lts. No quería revisar todos los repositorios y actualizar el pom para cada proyecto, así que Acabo de agregar el disableClassPathURLCheck a la llamada de línea de comando maven:

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

Usando maven surefire 2.21.0 resolví el problema cambiando el reuseForksvalor de la opción de verdadero a falso :

<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 mi sección de configuración en construcción se veía así:

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

Debe verificar si su máquina es de 64 bits o 32 bits. Si su máquina es de 32 bits, su argumento de memoria no debe exceder 4096, incluso debe ser inferior a 4 GB. pero si su máquina es de 64 bits, instale Java de 64 bits y proporcione JAVA_HOME en mvn.bat que apunta a la instalación de Java de 64 bits.

Conocí un caso en el que ninguna de las respuestas proporcionadas resolvió el problema. Fue con una aplicación heredada que utiliza log4j y SLF4J / logback.

La situación anterior: las clean testcompilaciones funcionaban bien cuando se iniciaban desde Eclipse, pero cuando se iniciaban en la línea de comando, se producía este error. Las construcciones de CI en CircleCI también funcionaron bien.

Lo que hice: por pura suposición, es configurar un correcto logback-test.xmly reducir la verbosidad del registro. He aquí que ya no experimenté este error y ahora puedo construir el proyecto (así como el módulo en el que se produjo este error) desde la línea de comandos.

Mi punto es que la forma en que se usan o configuran los marcos de registro puede ser otra explicación .

¿Fue realmente un conflicto entre log4j y logback? ¿O fue solo que el alto volumen de registro producido por las pruebas desbordó de alguna manera un búfer de línea de comando? No lo sé. Sigue siendo un misterio para mí.

Me enfrenté a un problema similar después de actualizar a java 12, para mí la solución fue actualizar la versión de jacoco <jacoco.version>0.8.3</jacoco.version>

La versión 2.22.2 tiene problemas reales con las JVM bifurcadas. Use la versión 2.20: ¡funciona de maravilla!

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

Recientemente me atasqué con este error mientras construía mis aplicaciones jar en contenedores con Bamboo:

org.apache.maven.surefire.booter.SurefireBooterForkException: la VM bifurcada finalizó sin decir adiós correctamente

Después de muchas horas de investigación lo arreglé. Y pensé que sería útil compartir mi solución aquí.

Por lo tanto, el error ocurre cada vez que Bamboo ejecuta el mvn clean packagecomando para aplicaciones Java en los contenedores acoplables. No soy un experto en Maven, pero el problema estaba en los complementos Surefire y Junit4 incluidos en spring-boot como dependencia de Maven.

Para solucionarlo, debe reemplazar Junit4 por Junit5 y anular el complemento Surefire en usted pom.xml.

1.Exclusión de inserción de dependencia de arranque de resorte interior:

<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. Agregue nuevas dependencias de 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. Inserte un nuevo complemento dentro de la sección de complementos

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

Eso debería ser suficiente para reparar las construcciones de bambú. No olvide también transformar todas las pruebas de Junit4 para admitir Junit5.

Configurar esto en pom.xml funcionó para mí. Pero debe consultar la documentación para otras soluciones 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>

La JVM bifurcada utilizada en la prueba se está quedando sin memoria. La solución sería desactivar la bifurcación de una JVM y ejecutar las pruebas en la JVM principal para garantizar que tenga suficiente memoria o pasar argumentos para aumentar la memoria de la JVM bifurcada

Mira la solución en esta respuesta

Me encontré con este problema durante las compilaciones de Jenkins en una máquina Ubuntu.

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

Por lo tanto, le di a la máquina Ubuntu más espacio de intercambio . Desde entonces, el problema se ha ido.

Mi resolución a este problema fue cerrar el maldito navegador Chrome que estaba ahogando la memoria de mi computadora 🙄

Puedes configurar las opciones de Java

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

En Windows (OpenJDK11, Maven 3.6.0, SUREFIRE 3.0.0-M1) obtuve esa causa raíz:

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

y se resolvió aumentando el tamaño del archivo de paginación, por ejemplo, de esta manera .

Probé todo lo anterior, no funcionó. La siguiente solución me funciona:

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

Tuve el mismo problema y lo resolví usando Java 8 de Oracle en lugar de Java 10 de Openjdk

Probé todas las soluciones proporcionadas (bifurcación, cargador de sistema, más memoria, etc.), nada funcionó.

Ambiente : la compilación falló en el entorno gitlab ci, ejecutando la compilación dentro de un contenedor acoplable.

Solución : utilizamos surefireplugin en la versión 2.20.1 y la actualización a 2.21.0 o superior (utilizamos 2.22.1) solucionó el problema.

Causa : SUREFIRE-1422 - surefire usa el comandops , que no estaba disponible en el entorno de la ventana acoplable y provocó el "bloqueo". Este problema se corrigió en 2.21.0 o superior.

Gracias a esta respuesta de otra pregunta: https://stackoverflow.com/a/50568662/2970422

También me encontré con este problema en MacOS mientras depuraba remotamente el código de prueba de Selenium en el puerto 5005. El problema resultó ser causado por una JVM sobrante de bifurcación segura que permaneció ejecutándose. La salida del registro al terminal IDE de Eclipse no mostró el problema subyacente que era la Dirección ya en uso . El mensaje de registro solo se mostró cuando ejecuté el mismo comando en un terminal MacOS que Eclipse realmente estaba intentando ejecutar:

/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

Matar la instancia JVM no autorizada (busque un nombre de proceso de Java en el Monitor de actividad) solucionó el problema. Por cierto, estoy ejecutando la versión 2.21.0 del complemento surefire sin problemas con open jdk 8 (v1.8.0_212). Tenga en cuenta que todas las rutas serán específicas para su entorno de compilación y posiblemente para el puerto (dirección = 5005).

Estaba enfrentando el mismo problema al ejecutar pruebas unitarias usando la prueba maven. Intenté cambiar las versiones infalibles pero no funcionó. Finalmente logré resolverlo de la siguiente manera: ANTES: (cuando el problema estaba sucediendo): javac es de jdk 1.8 java apuntaba al java bin desde jdk 1.11 CORRIENTE: (cuando el problema se resolvió): tanto javac como java apuntan a contenedores de jdk 1.8

Saludos Teja.

Experimenté este error después de que una variable miembro estática en mi clase de prueba llamó a un método para crear un objeto (que se usó en casos de prueba en toda la clase), y el método causó una excepción.

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

Algunas correcciones incluyen la recreación del objeto dentro de cada caso de prueba y la captura de cualquier excepción en consecuencia. O inicializando el objeto dentro de un método @BeforeTest y asegurándose de que esté construido correctamente.

En mi caso, el problema estaba relacionado con la ruta del espacio de trabajo que era demasiado larga. Así que hice una refactorización de ruta y esto me resolvió el problema.