java - Problemas con el complemento SureFire:-"La VM bifurcada terminó sin decir adiós correctamente. ¿Se colocó VM crash o System.exit? "

junit powermock (5)

Esto puede tener que ver con los derechos de administrador. Estaba enfrentando el mismo problema al ejecutar la instalación de build mvn clean install de Cygwin.

Ahora, cada vez que construyo, comienzo cygwin como "Ejecutar como administrador" y el problema se resuelve.

Esta pregunta ya tiene una respuesta aquí:

Estrategia para la depuración surefire "La VM bifurcada terminó sin decir adiós correctamente. VM crash o System.exit called? " 6 respuestas

Mientras se ejecutan pruebas unitarias después de la excepción ocurre:

org.apache.maven.lifecycle.LifecycleExecutionException: ExecutionException; nested exception is java.util.concurrent.ExecutionException: java.lang.RuntimeException: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:600) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

¿Alguna sugerencia?

Estaba enfrentando el mismo problema mientras ejecutaba maven goal "paquete". El problema se resolvió cuando ejecuté el objetivo "limpio" antes de ejecutar "paquete"

Estaba teniendo este mismo problema SOLAMENTE en jenkins como se informó en la respuesta aceptada y perdí una hora para darme cuenta de que el problema era que el nombre del trabajo de Jenkins tenía un espacio en él, esto era hacer algo (todavía no sé qué) en el la invocación del complemento seguro se vuelve loca ya que el nombre del trabajo es la carpeta dentro del espacio de trabajo de jenkins donde está todo.

Entonces, para ser claros, Jenkins no tiene nada que ver con el problema, solo lo vi en jenkins porque solo allí tuve un espacio en mi camino

Espero que esto ayude a alguien más. Esto estaba bajo seguro 2.14.1 y 2.16.

He tenido el mismo problema. Resultó que actualicé mis libs sin actualizar mi versión java, y tenía un poco demasiado nuevo servlet.jar. Encontré el siguiente mensaje en los registros, antes de la ''excepción de VM bifurcada'':

Caused by: java.lang.UnsupportedClassVersionError: javax/servlet/ServletRequest : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) at java.lang.ClassLoader.defineClass(ClassLoader.java:615) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getMethod0(Class.java:2670) at java.lang.Class.getMethod(Class.java:1603) at org.apache.maven.surefire.util.ReflectionUtils.tryGetMethod(ReflectionUtils.java:57) at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.isSuiteOnly(JUnit3TestChecker.java:64) at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.isValidJUnit3Test(JUnit3TestChecker.java:59) at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.accept(JUnit3TestChecker.java:54) at org.apache.maven.surefire.common.junit4.JUnit4TestChecker.accept(JUnit4TestChecker.java:51) at org.apache.maven.surefire.util.DefaultScanResult.applyFilter(DefaultScanResult.java:97) at org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:194) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:92)

La actualización de JVM ayudó.

¿Alguna sugerencia?

El mensaje de error de la excepción probablemente explica lo que está sucediendo. Una de tus pruebas unitarias tiene

llamado System.exit() , o
roto el arnés de prueba de la unidad, o
hecho algo que ha bloqueado la JVM en la que se estaba ejecutando.

No podemos decirte cual fue.

(Imagino que se informa el problema porque la JVM creadora esperaba que la JVM hija escribiera los resultados de la prueba unitaria en su salida estándar. Lo que le devolvió al niño le faltaba el mensaje (o lo que fuera) que decía que la unidad prueba había terminado. Es posible que la causa raíz sea diferente de las alternativas sugeridas, pero lo dudo, y es inútil especular ...)

Posiblemente hay más información en el archivo de registro para la prueba de la unidad ofensiva. Verifíquelos.