java - sistema - La máquina virtual bifurcada terminó sin decir adiós correctamente. Fallo VM o System.exit llamado

reparar vmdk dañado (25)

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

La máquina virtual bifurcada terminó sin decir adiós correctamente. Fallo VM o System.exit llamado

La forma de evitar este error es ejecutar su IDE como administrador.

"Causado por: java.util.concurrent.ExecutionException: java.lang.RuntimeException: la VM bifurcada terminó sin decir adiós correctamente. ¿Se colocó VM crash o System.exit?"

Este problema puede ocurrir si usa una versión no compatible de Java . Al igual que utiliza la nueva versión de Java, mientras que el código es compatible con alguna otra versión.

Conocí un caso cuando ninguna de las respuestas proporcionó una solución al problema. Fue con una aplicación heredada que usa log4j y SLF4J / logback.

La situación anterior: clean test compilaciones de clean test se ejecutaban correctamente cuando se lanzaron desde Eclipse, pero cuando se lanzó en la línea de comandos, se produjo este error. CI se basa en CircleCI funcionó bien también.

Lo que hice: por pura conjetura, es configurar un logback-test.xml y marcar la verbosidad del registro. Y he aquí, ya no experimenté este error y ahora puedo construir el proyecto (así como también el módulo en el que se estaba produciendo este error) desde la línea de comandos.

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

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

Cuando encontré este error fue debido a mi ulimit para archivos abiertos ( ulimit -n ) demasiado bajo. Se había (de alguna manera) configurado para solo 256:

% ulimit -n 256

El error desapareció después de haber aumentado el límite:

% ulimit -n 3072 % ulimit -n 3072

Es posible que su sistema no permita establecer el límite tan alto. por ejemplo, esto sucede cuando intento usar un número mayor:

% ulimit -n 3073 ulimit: setrlimit failed: invalid argument

O esto podría ser más bajo que su límite existente y podría enfrentar una causa raíz diferente.

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

En mi caso, el problema estaba relacionado con la ruta del espacio de trabajo, que era demasiado larga. Entonces hice un refactorio de ruta y esto me solucionó el problema.

En mi caso, el problema estaba relacionado con una salida de registro demasiado larga en la consola IntelliJ IDEA (SO Windows 10).

Mando:

mvn clean install

Este comando me resolvió el problema:

mvn clean install > log-file.log

En mi caso, olvidé agregar la dependencia en el pom:

<dependency> <groupId>org.aspectj</groupId> <artifactId>aspectjweaver</artifactId> <version>1.8.5</version> </dependency>

Solo asegúrate de elegir la versión correcta (ya que hoy es 1.8.9)

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

Surefire falla con el mensaje "La máquina virtual bifurcada terminó sin decir adiós correctamente"
Surefire no admite pruebas ni bibliotecas referenciadas que llamen a System.exit () en cualquier momento. Si lo hacen, son incompatibles con el fuego seguro y probablemente debas presentar un problema con la biblioteca / proveedor. Alternativamente, la VM bifurcada también podría bloquearse por varias razones, lo que también puede hacer que este problema suceda. Busque los archivos clásicos "hs_err *" que indican bloqueos de VM o examine el resultado del registro ejecutando maven cuando se ejecutan las pruebas. Algunos resultados "extraordinarios" de los procesos de bloqueo se pueden descargar a la consola / registro. Si esto sucede en un entorno de CI y solo después de un tiempo de ejecución, existe una buena probabilidad de que su suite de pruebas pierda algún tipo de recurso de nivel de sistema operativo que empeora las cosas en cada ejecución. Las herramientas de monitoreo de nivel de os regulares pueden darle alguna indicación.

Esto funcionará definitivamente ...

Agregue las siguientes líneas en el archivo POM y proporcione una compilación.

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

Esto puede ocurrir debido a una memoria inadecuada. Asegúrese de no tener ninguna aplicación ejecutándose en segundo plano mientras ejecuta mvn. En mi caso, Firefox se estaba ejecutando en segundo plano con un alto uso de memoria.

Esto también podría suceder debido a un problema totalmente diferente. Por ejemplo, en mi caso, nuestra compilación de Jenkins estaba fallando intermitentemente mientras se ejecutaban las pruebas sin ningún motivo.

Revisé nuestras pruebas para encontrar cualquier aparición de System.exit() pero no había ninguna.

Después de más excavaciones descubrí que esto podría estar sucediendo debido a un error JDK que podría haber causado esta regresión.

JDK-6675699

Todavía estoy trabajando en hacer esta corrección en nuestras compilaciones, volveré y actualizaré el hilo nuevamente.

Experimenté este error después de que una variable miembro estática en mi clase de prueba llamara 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 volver a crear el objeto dentro de cada caso de prueba y detectar cualquier excepción en consecuencia. O inicializando el objeto dentro de un método @BeforeTest y asegurándose de que esté construido correctamente.

Hace poco me quedé con este error al construir mis aplicaciones jar en contenedor con Bamboo:

org.apache.maven.surefire.booter.SurefireBooterForkException: la VM bifurcada terminó 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í.

Entonces, el error ocurre cada vez que bamboo ejecuta el mvn clean package para aplicaciones java en los contenedores de docker. No soy experto en Maven, pero el problema estaba en los complementos Surefire y Junit4 incluidos en spring-boot como maven dependency.

Para solucionarlo, debe reemplazar Junit4 para Junit5 y anular el plugin Surefire en su pom.xml .

1.Insección de inserción de la dependencia de arranque de primavera:

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope>  </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. Insertar un nuevo plugin 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 construcciones de bambú. No olvides también transformar todas las pruebas de Junit4 para admitir Junit5.

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

/var/log/syslog reportado 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.

Puede ser porque ha aplicado algunos cambios en su proyecto y no ha actualizado todas sus referencias.

En mi caso, recibí este error porque actualicé los nombres de los paquetes en mi proyecto, pero olvidé actualizar sus referencias en el archivo TestNG.xml. Al corregirlo, resolví este error.

Recientemente travis mató la ejecución de una prueba (¡sin haber cambiado nada relacionado (y compilaciones exitosas en máquinas desarrolladoras)!), Por lo tanto, INCORPORAR FALLAS . Una de las causas fue esta (ver la respuesta @agudiana):

Surefire no es compatible con las pruebas ni con las bibliotecas a las que se hace referencia que llaman a System.exit () `

(dado que la clase de prueba de hecho se llama System.exit(-1) ).

Usar una declaración de return simple en return lugar ayuda.
Para hacer feliz a Travis nuevamente, también tuve que agregar los parámetros surefire ( <argLine> ) proporcionados por @xiaohuo. (también, tuve que eliminar -XX:MaxPermSize=256m para poder construir en uno de mis escritorios)

Hacer solo una de las dos cosas no funcionó.

Para obtener más información de fondo, ¿ cuándo deberíamos llamar a System.exit en Java ?

Si alguien incluye un argumento argLine personalizado, debe reconsiderarlo porque es probable que sea el origen de sus problemas con la asignación de memoria.

Por ejemplo (solía tener):

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

Ahora uso valores específicos duros:

<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 experimenté esto, pero en mi caso, había escrito un gancho personalizado para pepino

public class MappingFormatter implements gherkin.formatter.Formatter {

...

uno de mis métodos estaba produciendo una excepción de puntero nulo, lo que provocó que el seguro saliera sin registrar el error.

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

Descripción del problema

El problema es con el complemento maven maven-surefire-plugin solo en la versión 2.20.1 y 2.21.0. Lo revisé y utilizas la versión 2.20.1.

Solución 1

Actualizar la versión del complemento a 2.22.0 . Agregar 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 complemento de versión anterior a 2.20 . Agregar 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 configuración de plugin testFailureIgnore . Agregar en pom.xml :

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

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 Cannot use a threadCount parameter less than 1; 1 > 0 . Al agregar <threadCount>1</threadCount> en la configuración de surefire-plugin, el otro error desapareció.

Configuración completa del complemento:

<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 tanto junit como testng en este marco de prueba por razones de compatibilidad con versiones anteriores.

Tuve el mismo problema que tratar de compilar un proyecto maven establecido en 1.7 en un entorno de Windows 10 con JAVA = 1.8.

Lo resolví cambiando la versión de Java de 1.7 a 1.8 como se muestra a continuación.

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

Tuve el mismo problema y lo resolví agregando:

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

Todo el elemento de 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>

Tuve un problema similar al ejecutar el comando mvn con el complemento de 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 de JDK (creo que funciona una versión menor más nueva)

para mí funcionó con

mvn clean install -DskipTests -e