Error "Forked Java VM exit abnormally" de pruebas junit

ant hudson

Question

Tengo una prueba junit java que pasa cuando se ejecuta solo en una máquina de desarrollo. También tenemos un trabajo hudson que ejecuta todas las pruebas, invocadas a través de ant, en un nodo Mac OS X 10.4 con Java 1.5. La prueba estaba pasando en la compilación de hudson hasta hace poco pero ahora (sin cambios de código relacionados) una prueba falla cada vez con el siguiente error:

Mensaje de error

La VM Java forked salió de manera anormal. Tenga en cuenta que el tiempo en el informe no refleja el tiempo hasta que la VM salga.

Stacktrace

junit.framework.AssertionFailedError: la VM Java forked salió de manera anormal. Tenga en cuenta que el tiempo en el informe no refleja el tiempo hasta que la VM salga.

googlear muestra que muchos otros parecen haber encontrado el mismo problema, pero no pude encontrar ninguna respuesta.

Answer 1

Creo que vi este error una vez cuando terminé con múltiples versiones de junit en mi classpath. Podría valer la pena echarle un vistazo.

Answer 2

En mi caso, el classpath en el que se ejecutaban mis pruebas excedía la longitud máxima permitida por el sistema operativo para una variable de entorno (también conocido como el problema de Linux Classpath demasiado largo).

La solución fue crear un contenedor de rutas . Pasos simplificados:

1. Usa jar (o tu IDE) para hacer un jar de tu proyecto, lo llamaremos MyProject.jar

2. Haga un archivo llamado Manifest.txt con el texto

Class-Path: MyProject.jar

3. Ejecute la línea de comandos de jar esto

jar cfm PathingJar.jar manifest.txt MyRootPackage / *. class

Luego, en su herramienta de compilación, ejecute su directiva de prueba contra el contenedor de la ruta en sí (no mezcle en otras clases o jarras). Luego pude hacer que mis pruebas se ejecutaran sin esa excepción.

Answer 3

En mi caso, es una excepción no detectada en un inicializador / método / bloque estático dentro de una clase.

Específicamente, tuve una clase que llamaba a un método estático en otra clase y estaba activando una NumberFormatException.

Por cierto, agregar "showoutput = true" a la tarea en build.xml no ayudó a solucionar problemas. Dado que el bloqueo estático es uno de los primeros elementos que se ejecuta, la JVM explotó antes de que pudiera dar salida a nada.

Answer 4

Enfrenté el mismo problema. El problema era con la generación de código byte con burla de la clase Config; Cambiamos la importación a

import static org.junit.Assert.assertNotNull;
import static org.mockito.Mockito.times;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

Y funcionó.

Answer 5

Enfrenté un problema similar. Ejecuté las pruebas junit como una tarea de hormiga. Agregué el showoutput = "sí" propiedad ant junit y ejecuté la tarea junit hormigas. A continuación, mostró la traza de la pila de excepción que provocó la salida de la jvm bifurcada.

Answer 6

Esto puede ocurrir cuando se lanza una RuntimeException no detectada. Lamentablemente, la tarea junit no genera la excepción, por lo que no hay una manera fácil de determinar la causa raíz. Puede solucionar esto ejecutando el caso de prueba desde la línea de comando donde se mostrará la excepción.

java <vm-args> org.junit.runner.JUnitCore <test-class-name>

En mi caso, se lanzó una excepción IllegalArgumentException.

Answer 7

Me enfrenté al problema después de reinstalar una nueva versión de NetBeans en un disco duro externo, actualizando Junit al mismo tiempo y usando mi viejo espacio de trabajo.

Para mí, la solución al mismo problema fue simple:

Simplemente agregue JUnit-Library a project properties => Libraries => Compile Tests and Run Tests .

Entonces, en mi caso, era solo una biblioteca faltante o un conflicto de versión JUnit.

Answer 8

Para mí, fue un "java.lang.OutOfMemoryError" en la VM bifurcada (tarea junit con fork = "yes") que hizo que este mensaje apareciera en la máquina virtual principal.

OutOfMemory era visible en el registro de hormigas (bueno, es visible ya que todavía está presente).

Uso hormiga 1.7.1, así que no hay esperanza con la actualización de hormiga.

Después de poner los mismos parámetros de VM en "Ejecutar> Herramientas externas> Herramientas externas> JRE" que en Eclipse.ini (-Xms40m -Xmx512m -XX: MaxPermSize = 256M), el problema está resuelto.

Mantengo el tenedor en "no" para estar seguro de usar los parámetros.

Answer 9

Para nosotros, fue en realidad que por accidente (usamos una versión más nueva de eclipse) comenzamos a usar Ant 1.7.x en lugar de nuestra versión anterior de hormiga, que era compatible con nuestro entorno Weblogic 8.1 / JDK 1.4.x. Arreglamos esto cambiando el Ant Home en Eclipse-> Windows-> Preferences-> Ant-> Runtime a nuestra versión anterior de Ant.

Saludos Klas

Answer 10

Solucioné mi problema estableciendo la siguiente variable de entorno:

Variable: _JAVA_OPTIONS Valor: -Xms128m -Xmx512m

Answer 11

Tengo múltiples junit jar en mi classpath. uno es de hormiga y otro de WAS. Cuando lo eliminé, el error desapareció ... La versión Ant que estoy usando 1.8

Answer 12

Tuve este problema también. Cambiar la tarea junit de:

<batchtest fork="yes" ... />

a

<batchtest fork="no" ... />

me lo arregló Aunque no entiendo totalmente esta área de la hormiga o por qué esto lo solucionaría. En mi caso, fue un error en "BeforeFirstTest" y creo que es un error debido a dos archivos ant en mi classpath (que probablemente sea lo que debería corregir)

Creo que el problema está en una de las versiones de horm: http://track.pmease.com/browse/QB-500;jsessionid=C1CF6999CBBDB5097A9CFCF4A11AF6C0?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

ETA: Creo que batchtest = "no" en realidad cambia la ruta de clase y, por lo tanto, da como resultado la exclusión de mi tarro de hormigas ofensivas.

Answer 13

Tuve este problema y resulta que el proceso en realidad estaba llamando a System.exit (). Sin embargo, también había un error en Ant donde esto aparecía a veces. Creo que Ant 1.7.1 tiene el error corregido. Así que asegúrese de ejecutar esa versión.

Answer 14

Tuve exactamente lo mismo hace un tiempo. El problema es que se llama a System.exit () en algún lugar. Sin embargo, puede ser difícil de encontrar, ya que la llamada podría provenir de tu código o de una de las bibliotecas que utilizas.

Answer 15

TestNG biblioteca TestNG bibliotecas de prueba y solucionó el problema.

Answer 16

Es la VM chocando? ¿Puedes encontrar un archivo de volcado (llamado hs_err_pid*.log )? Si ese es el caso, el archivo de volcado le dará pistas sobre por qué se está rompiendo.