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

192

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
un montón
fuente
77
Vuelva a ejecutar Maven con -e y -X como sugiere la salida, y pegue lo que le da. Además, ¿está creando su propio código o una biblioteca existente? Si está creando su propio código, ¿está llamando a System.exit (int) en alguna parte? Si está construyendo una biblioteca existente, ¿de dónde obtuvo la fuente?
Dylon
@Dylon Edwards: es un código fuente existente, proyecto OpenDayLight para la implementación de SDN.
ataque el
Un escenario reciente que tuve que reproduce el problema fue cuando ejecuté conjuntos de pruebas desde archivos xml. En caso de que un archivo xml defina una clase que ya no existe o se refiera al antiguo nombre completo de una clase que se ha movido, la JVM no puede cargar la clase. Esto da como resultado el extraño mensaje que has observado. Mirar más de cerca a cualquier seguimiento de pila podría ayudarlo a identificar tales problemas, no es necesario pasar los modificadores -e o -X en este caso.
Ivaylo Slavov
@astack, ¿cuál fue la solución para esto? ¿podría marcar una respuesta o escribir la suya por favor?
Naman

Respuestas:

122

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>
xiaohuo
fuente
77
+1 Usé este fragmento, textualmente, y solucionó mi problema con Travis-CI. No recibíamos esto en ninguna de las estaciones de trabajo de nuestros desarrolladores.
InicioGuy
77
Lo anterior no solucionó el problema para mí. Este problema 'puede' ocurrir cuando una de las dependencias (jar, etc.) .m2está dañada. Eliminar ~ / .m2 / repositorio rm -rf ~/.m2/repositoryy luego lo mvn installresolvió por mí.
ch4nd4n
2
Copié y pegué esto en mi archivo pom y funcionó de
maravilla
8
Advertencia de VM de servidor OpenJDK de 64 bits: ignorando la opción MaxPermSize = 256m; el soporte fue eliminado en 8.0
Julien
2
¿Podría alguien explicar qué hace realmente y qué efectos tiene?
borgmater
72

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
Mikhail
fuente
¡El hecho de que los registros fueran demasiado largos también fue un problema para mí! La redirección a un archivo de registro no ayudó. Cambiar algunas de las declaraciones de registro más comunes, de información a depuración, resolvió el problema
RvPr
77
¡Demasiado registro fue un problema real en mi caso!
Changwon Choe
1
No olvide también la secuencia de error: mvn clean test 2> err.txt 1> out.txt o mvn clean test> out.txt 2> & 1 o mvn clean test 2> & 1 | tee out.txt Al redirigir, puede ver la salida en otra consola con menos + F out.txt
radzimir
1
Para mí, el cambio de Windows cmd a la consola Intellij lo resolvió.
Brócoli
3
De hecho, la redirección al archivo de registro resuelve este problema.
horizon7
41

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>
Michał Orliński
fuente
Para mí, esta combinación funcionó gracias: <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-surefire-plugin </artifactId> <version> 2.22.1 </version> <configuration> < testFailureIgnore> true </testFailureIgnore> </configuration> </plugin>
Abhishek
Gracias por esto, usar la maven:3.6.0-jdk-10imagen de Docker y actualizar a la versión 3.0.0-M3de maven-surefire-pluginresuelto también para mí.
danialk
21
Con respecto a la Solución 3: ¿Podemos realmente decir que ignorar las fallas de las pruebas es una solución? ¿De qué sirve hacerse pruebas si su resultado no tiene sentido?
Ulukai
¡Acabo de actualizar maven-surefire-plugin a 2.22.2 y funciona bien!
Krzysztof Walczewski
¡Sip! La actualización a v2.22.2 de surefire también lo resolvió para mí. ¡Gracias!
Migs el
32

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
majikman
fuente
1
Gracias. Cambiar de 1.8.0_161-b12 a 11.0.1 + 13 ayudó en nuestro caso.
Karussell el
1
Este es el problema exacto que estaba enfrentando en mi Jenkins y ahora está resuelto. Gracias.
Vighnesh Pai
OP tenía otro mensaje de error:The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
PetroCliff
1
@PetroCliff Reconocí que ese era el error que también recibía cuando dije "notamos que nuestras compilaciones se rompían en Jenkins con este error ". Luego procedí a explicar que el error era engañoso y que el error real estaba en surefire-reports.
majikman
25

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.

agudian
fuente
9

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>
Mahmoud dijo
fuente
1
Un simple agregado de una versión más reciente 3.0.0-M1 (por ejemplo) ha resuelto el problema.
Galigator
6

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

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

javabeangrinder
fuente
6

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)

andreyro
fuente
6

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>
Loi Cao
fuente
1
Este es el que me lo arregló. He estado construyendo maven a través de artefactos en una imagen acoplada en cola de gitlab. Ha sido difícil hacer que funcione una configuración representativa y después de probar muchas opciones para la configuración segura, esta la arregló con la versión 2.22.0.
Richard Bown
1
tengo que agregar esta opción para cada trabajo experto en Gitlab CI y no tengo idea de por qué.
cljk
5

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.

Chad Van De Hey
fuente
5

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"
Kevin Dubois
fuente
5

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>
Csaki Istvan
fuente
4

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.

Naresh Singh
fuente
4

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

AbVog
fuente
Votación positiva porque esto realmente puede resolver / evitar / esquivar el problema. Estoy usando slf4j y sl4j-simple en Windows y la salida lenta también me señaló en esta dirección. Configuración de System.setProperty (SimpleLogger.DEFAULT_LOG_LEVEL_KEY, "warn"); Hizo el truco. La degradación de maven-surefire-plugin a 2.18.1 también funcionó.
marcus
4

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>

Max Vorontsov
fuente
Este fue de hecho el problema que estaba teniendo con mi proyecto. Lástima que esta respuesta no sea tan visible ...
OmriYaHoo
4

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>
Alex
fuente
Hmm, esto realmente ayuda!
Zhen Zhang
Sí, v2.22.2tiene un problema con maven:3.6-jdk-8-alpine. ¡Muy molesto!
KimchiMan
3

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.

ripreal
fuente
2

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>
Gryffe
fuente
2

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

Muji
fuente
1

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

Anand Rockzz
fuente
1

Puedes configurar las opciones de Java

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

abhimanyu
fuente
1

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 .

Radoslav Ivanov
fuente
En Linux (4.4.0-145-generic, amd64), cambió de Oracle JRE 8 a AdoptOpenJDK_8u202b08 para un trabajo de Jenkins y comenzó a producir el error "fork": - "Ejecución-prueba predeterminada del objetivo org.apache.maven.plugins : maven-surefire-plugin: 2.19.1: prueba fallida: la VM bifurcada finalizó sin decir adiós correctamente. ¿Se produjo un bloqueo de VM o System.exit? " - Cambió de nuevo a Oracle JRE y el error se detuvo. Este es el único trabajo (nuestro de aproximadamente 300) que tiene este problema. Afortunadamente, es solo un proyecto interno, no un cliente entregable, podemos mantenerlo en Sun / Oracle JRE.
Robert
1

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>

Yuebing Cao
fuente
Esta versión exacta del complemento me ayudó. Mi configuración, por cierto, es: Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T21:41:47+03:00) Java version: 1.8.0_201, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.0_201\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
tworogue
1

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

Francesco Borzi
fuente
1

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

bufón
fuente
1

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

Gregg Leichtman
fuente
1

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.

teja
fuente
0

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.

usuario2812481
fuente
0

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.

thiago-devel
fuente
¿Eso estaba en una máquina de Windows?
hithwen
Sí, se está ejecutando en Windows.
thiago-devel
¿Cómo encontraste eso?
dzieciou