La machine virtuelle fourchue s'est terminée sans dire au revoir correctement. Crash de la VM ou System.exit appelé

Aidez-moi à résoudre ce problème. Je ne comprends pas exactement ce que signifie l'erreur dans le journal.

[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

J'ai eu le même problème et résolu en ajoutant:

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

L'ensemble de l'élément plugin est:

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

Dans mon cas, le problème était lié à une sortie de journal trop longue dans la console IntelliJ IDEA (OS Windows 10).

Commander:

mvn clean install

Cette commande m'a résolu le problème:

mvn clean install > log-file.log

J'ai un problème très similaire ( build Maven et maven-failafe-plugin - La machine virtuelle fourchue s'est terminée sans dire au revoir correctement ) et j'ai trouvé trois solutions qui fonctionnent pour moi:

Description du problème

Le problème est avec le plugin maven maven-surefire-plugin uniquement dans les versions 2.20.1 et 2.21.0. J'ai vérifié et vous utilisez la version 2.20.1.

Solution 1

Mettez à niveau la version du plugin vers 2.22.0 . Ajoutez pom.xml :

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

Solution 2

Rétrograder la version du plugin à 2.20 . Ajoutez pom.xml :

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

Solution 3

Utilisez la configuration du plugin testFailureIgnore . Ajoutez pom.xml :

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

À partir d'aujourd'hui (30/10/2018), nous avons remarqué que nos builds se cassaient dans Jenkins avec cette erreur.

L'erreur est un peu trompeuse et nécessite de regarder la sortie du vidage target/surefire-reports/ pour voir le message d'erreur suivant:

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

Cela m'amène au post SO suivant qui mentionne un possible bug dans OpenJDK 181: Maven surefire n'a pas pu trouver la classe ForkedBooter

L'un ou l'autre des correctifs de cet article résout mon problème. Pour être précis, j'ai utilisé l'un ou l'autre de ces éléments:

1. Passer de la création dans le conteneur Docker maven:3.5.4-jdk-8àmaven:3.5.4-jdk-8-alpine
2. Remplacement du chargeur de classe de Spring Boot détaillé ici: https://stackoverflow.com/a/50661649/1228408

Cette partie de la FAQ Surefire peut vous aider:

Surefire échoue avec le message "La machine virtuelle fourchue s'est terminée sans dire au revoir correctement"

Surefire ne prend à aucun moment en charge les tests ou les bibliothèques référencées appelant System.exit (). S'ils le font, ils sont incompatibles avec surefire et vous devriez probablement signaler un problème avec la bibliothèque / le fournisseur. Alternativement, la machine virtuelle fourchue pourrait également tomber en panne pour un certain nombre de raisons, ce qui peut également provoquer ce problème. Recherchez les fichiers classiques "hs_err *" indiquant les plantages de VM ou examinez la sortie du journal de l'exécution de maven lorsque les tests s'exécutent. Certaines sorties "extraordinaires" de processus en panne peuvent être sauvegardées dans la console / le journal. Si cela se produit dans un environnement CI et seulement après un certain temps, il y a de fortes chances que votre suite de tests fuit une sorte de ressource au niveau du système d'exploitation qui aggrave les choses à chaque exécution. Des outils de surveillance réguliers au niveau du système d'exploitation peuvent vous donner des indications.

Faisait face au même problème, java 8 sur ubuntu

puis est tombé sur https://stackoverflow.com/a/53016532/1676516

Cela semble être un bug récent dans la version 2.22.1 du plugin surefire avec java 8 https://issues.apache.org/jira/browse/SUREFIRE-1588

suivi la solution de contournement suggérée via les paramètres mvn locaux ~/.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>

J'ai eu le même problème aujourd'hui et pour moi, le vrai problème a été signalé plus haut dans le journal avec un message Cannot use a threadCount parameter less than 1; 1 > 0 . Lors de l'ajout<threadCount>1</threadCount> de la configuration du plugin surefire, l'autre erreur a disparu.

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

... et oui, j'utilise à la fois junit et testng dans ce cadre de test pour des raisons de compatibilité descendante.

Problème similaire lors de l'exécution de la commande mvn avec le plugin Jacoco sur 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?

Il y avait un bogue dans JDK https://bugs.openjdk.java.net/browse/JDK-8081379

Et la solution était d'exécuter mvn clean install avec le paramètre -XX: -UseLoopPredicate

Ou faites simplement une mise à jour vers JDK (je pense que la nouvelle version mineure fonctionne)

Désactiver useSystemClassLoader de maven-surefile-plugin devrait aider

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

Si quelqu'un inclut un argument argLine personnalisé, vous devez reconsidérer car il est probablement la source de vos problèmes d'allocation de mémoire.

Par exemple (j'avais l'habitude d'avoir):

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

Maintenant, j'utilise des valeurs spécifiées en dur:

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

Quelle qu'en soit la raison, les applications qui s'intègrent à Surefire telles que Jacoco ne demandent pas suffisamment de mémoire pour coexister avec les tests effectués au moment de la construction.

J'ai également rencontré ce problème dans un conteneur Jenkins Docker (j'ai essayé jenkins: lts, ​​jenkins, jenkins: slim et jenkins: slim-lts. Je ne voulais pas parcourir tous les référentiels et mettre à jour le pom pour chaque projet, alors je vient d'ajouter disableClassPathURLCheck à l'appel de ligne de commande maven:

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

En utilisant maven surefire 2.21.0, j'ai résolu le problème en changeant la reuseForksvaleur de l' option de true à false :

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

Toute ma section de configuration sous build ressemblait à ceci:

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

Vous devez vérifier si votre machine est 64 bits ou 32 bits. Si votre machine est 32 bits, votre argument de mémoire ne doit pas dépasser 4096, même s'il doit être inférieur à 4 Go. mais si votre machine est 64 bits alors, installez Java 64 bits et fournissez JAVA_HOME dans mvn.bat qui pointe vers l'installation java 64 bits.

J'ai rencontré un cas où aucune des réponses fournies n'a résolu le problème. C'était avec une application héritée qui utilise log4j et SLF4J / logback.

La situation précédente: les clean testbuilds fonctionnaient correctement lors du lancement à partir d'Eclipse, mais lors du lancement dans la ligne de commande, cette erreur s'est produite. CI s'appuie sur CircleCI a bien fonctionné aussi.

Ce que j'ai fait: par pure conjecture, est de configurer un bon logback-test.xml et réduire la verbosité de la journalisation. Et voilà, je n'ai plus rencontré cette erreur et je peux maintenant construire le projet (ainsi que le module dans lequel cette erreur se produisait) à partir de la ligne de commande.

Mon point est que la façon dont les cadres de journalisation sont utilisés ou configurés peut être une autre explication .

Était-ce vraiment un conflit entre log4j et logback? Ou est-ce simplement que le volume élevé de journalisation produit par les tests a en quelque sorte débordé un tampon de ligne de commande? Je ne sais pas. Cela reste un mystère pour moi.

J'ai rencontré un problème similaire après la mise à niveau vers java 12, pour moi, la solution consistait à mettre à jour la version jacoco <jacoco.version>0.8.3</jacoco.version>

la version 2.22.2 a de réels problèmes avec les JVM fourchus. Utilisez la version 2.20 - cela fonctionne comme un charme!

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

Je me suis récemment retrouvé avec cette erreur lors de la création de mes applications jar conteneurisées avec Bamboo:

org.apache.maven.surefire.booter.SurefireBooterForkException: la machine virtuelle forkée s'est terminée sans dire au revoir correctement

Après de nombreuses heures de recherche, je l'ai réparé. Et j'ai pensé qu'il serait utile de partager ma solution ici.

Ainsi, l'erreur se produit chaque fois que bamboo exécute la mvn clean packagecommande pour les applications Java dans les conteneurs docker. Je ne suis pas un expert Maven mais le problème était dans les plugins Surefire et Junit4 inclus dans spring-boot en tant que dépendance maven.

Pour résoudre ce problème, vous devez remplacer Junit4 par Junit5 et remplacer le plugin Surefire en vous pom.xml.

1.Exclusion d'insertion de dépendance de démarrage à ressort intérieur:

<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. Ajoutez de nouvelles dépendances 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. Insérez un nouveau plugin dans la section plugins

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

Cela devrait suffire à réparer les constructions en bambou. N'oubliez pas également de transformer tous les tests Junit4 pour prendre en charge Junit5.

Définir cela dans pom.xml a fonctionné pour moi. Mais vous devriez consulter la documentation pour d'autres solutions de contournement 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 machine virtuelle Java forkée utilisée dans le test manque de mémoire. La solution serait soit de désactiver le forking d'une JVM et d'exécuter les tests sur la JVM principale en vous assurant d'avoir suffisamment de mémoire, soit de passer des arguments pour augmenter la mémoire de la JVM fourchue

Découvrez la solution dans cette réponse

J'ai rencontré ce problème lors de la compilation de Jenkins sur une machine Ubuntu.

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

J'ai donc donné plus d'espace de swap à la machine Ubuntu . Depuis, le problème a disparu.

Ma résolution à ce problème était de fermer le foutu navigateur Chrome qui étouffait la mémoire de mon ordinateur 🙄

Vous pouvez définir les options Java

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

Sous Windows (OpenJDK11, Maven 3.6.0, SUREFIRE 3.0.0-M1), j'ai cette cause fondamentale:

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

et résolu en augmentant la taille du fichier d'échange, par exemple comme ceci .

essayé tout ci-dessus, n'a pas fonctionné. la solution ci-dessous fonctionne pour moi:

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

J'ai eu le même problème et résolu en utilisant Java 8 d'Oracle au lieu de Java 10 d'Openjdk

J'ai essayé toutes les solutions proposées (forking, systemloader, plus de mémoire etc.), rien n'a fonctionné.

Environnement : la compilation a échoué dans l'environnement gitlab ci, en exécutant la compilation dans un conteneur docker.

Solution : nous avons utilisé surefireplugin dans la version 2.20.1 et la mise à niveau vers la version 2.21.0 ou supérieure (nous avons utilisé la version 2.22.1) a résolu le problème.

Cause : SUREFIRE-1422 - surefire utilise la commandeps , qui n'était pas disponible dans l'environnement docker et a conduit au "crash". Ce problème est résolu dans la version 2.21.0 ou supérieure.

Merci à cette réponse d'une autre question: https://stackoverflow.com/a/50568662/2970422

J'ai également rencontré ce problème sur MacOS lors du débogage à distance du code de test Selenium sur le port 5005. Le problème s'est avéré être causé par un reste de JVM infaillible qui restait en cours d'exécution. La sortie du journal vers le terminal Eclipse IDE n'a pas montré le problème sous-jacent qui était l' adresse déjà utilisée . Le message du journal n'a été affiché que lorsque j'ai exécuté la même commande dans un terminal MacOS qu'Eclipse essayait réellement d'exécuter:

/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

La suppression de l'instance JVM non autorisée (recherchez un nom de processus Java dans Activity Monitor) a résolu le problème. Au fait, j'exécute la version 2.21.0 du plugin surefire sans problème avec open jdk 8 (v1.8.0_212). Notez que tous les chemins seront spécifiques à votre environnement de construction et éventuellement au port (adresse = 5005).

J'étais confronté au même problème lors de l'exécution de tests unitaires à l'aide de maven test. J'ai essayé de changer les versions infaillibles mais cela ne fonctionnait pas. Finalement réussi à résoudre comme suit: EARLIER: (lorsque le problème se produisait): javac est de jdk 1.8 java pointait vers le bin java de jdk 1.11 COURANT: (lorsque le problème a été résolu): javac et java pointent vers le bacs de jdk 1.8

Cordialement Teja.

J'ai rencontré cette erreur après qu'une variable membre statique de ma classe de test a appelé une méthode pour créer un objet (qui a été utilisée dans les cas de test dans toute la classe), et la méthode a provoqué une exception.

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

Certains correctifs incluent la recréation de l'objet dans chaque scénario de test et la détection des exceptions en conséquence. Ou en initialisant l'objet dans une méthode @BeforeTest et en s'assurant qu'il est construit correctement.

Dans mon cas, le problème était lié au chemin de l'espace de travail qui était trop long. J'ai donc refait le chemin et cela m'a résolu le problème.