web-dev-qa-db-fra.com

La fourchette VM terminé sans dire proprement au revoir. VM crash ou System.exit appelé

S'il vous plaît 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
javamaven-surefire-pluginopendaylight
96
astack

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

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

L'élément plugin entier 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>
61
xiaohuo

À compter d’aujourd’hui (30/10/2018), nous avons remarqué que nos versions déferlaient à Jenkins avec cette erreur.

L'erreur est un peu trompeuse et nécessite de regarder la sortie du dump dans 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 suivant SO qui mentionne un bug possible dans OpenJDK 181: Maven surefire n’a pas pu trouver la classe ForkedBooter

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

  1. Passer de la construction du conteneur de menu fixe maven:3.5.4-jdk-8 à maven:3.5.4-jdk-8-Alpine
  2. Remplacer le chargeur de classes de Spring Boot détaillé ici: https://stackoverflow.com/a/50661649/1228408
28
majikman

J'ai un problème très similaire ( Maven build et maven-failafe-plugin - Le forked VM s'est terminé sans dire au revoir ) et a trouvé trois solutions qui fonctionnent pour moi:

Description du problème

Le problème est avec maven plugin 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. Ajouter dans 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 vers 2.20. Ajouter dans 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. Ajouter dans pom.xml:

<plugin>
  <groupId>org.Apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <testFailureIgnore>true</testFailureIgnore>
  </configuration>
</plugin>
21
Michał Orliński

Cette partie de Surefire FAQ pourrait vous aider:

Surefire échoue avec le message "Le forked VM s'est terminé sans dire au revoir correctement"

Surefire ne prend pas en charge les tests ni les bibliothèques référencées appelant System.exit () à tout moment. S'ils le font, ils sont incompatibles avec surefire et vous devriez probablement signaler un problème à la bibliothèque/au fournisseur. Sinon, le fichier forké VM pourrait également se bloquer pour un certain nombre de raisons, ce qui peut également rendre ce problème possible. Recherchez les fichiers classiques "hs_err *" indiquant VM - plante ou examinez la sortie du journal à partir de l'exécution de maven lors de l'exécution des tests. Certaines sorties "extraordinaires" des processus bloqués peuvent être transférées vers la console/le journal. Si cela se produit dans un environnement CI et après un certain temps, il y a de bonnes chances que votre suite de tests laisse filtrer 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 de l’os peuvent vous donner quelques indications. 

17
agudian

Je viens de faire face au même problème, Java 8 sur Ubuntu

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

Il semble qu’un bogue récent se soit produit dans le plugin surefire version 2.22.1 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>
9
Mahmoud Said

Si quelqu'un inclut un argument argLine personnalisé, vous devez reconsidérer votre choix car il est probablement à l'origine 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 précises spécifiées:

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

Pour une raison quelconque, les applications qui s’intègrent à Surefire, telles que Jacoco, ne demandent pas assez de mémoire pour coexister avec les tests qui ont lieu au moment de la construction.

5
Chad Van De Hey

Avait un problème similaire lors de l'exécution de la commande mvn avec le plug-in 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 bug dans JDK https://bugs.openjdk.Java.net/browse/JDK-8081379

Et la solution consistait à exécuter mvn clean install avec le paramètre -XX: -UseLoopPredicate 

Ou simplement mettre à jour JDK (je pense que la version mineure la plus récente fonctionne)

5
andreyro

J'ai eu le même problème aujourd'hui et pour moi le problème réel a été rapporté plus haut dans le journal avec le message Cannot use a threadCount parameter less than 1; 1 > 0. Lors de l'ajout de <threadCount>1</threadCount> dans 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 junit et testng dans ce cadre de test pour des raisons de compatibilité ascendante.

5
javabeangrinder

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

Commander:

mvn clean install

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

mvn clean install > log-file.log
4
Mikhail

Désactivez useSystemClassLoader du plugin maven-surefile devrait vous aider

        <plugin>
            <groupId>org.Apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.22.0</version>
            <configuration>
                <useSystemClassLoader>false</useSystemClassLoader>
            </configuration>
        </plugin>
4
Loi Cao

J'ai rencontré ce problème également dans un conteneur Jenkins Docker (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 de chaque projet. vient d'ajouter le disableClassPathURLCheck à l'appel de ligne de commande maven:

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

Vous devez vérifier si votre machine est 64 bits ou 32 bits. Si votre machine est en 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 en 64 bits, installez Java 64 bits et indiquez Java_HOME dans mvn.bat, qui pointe vers une installation Java 64 bits.

3
Naresh Singh

J'ai récemment rencontré cette erreur lors de la création de mes applications de conteneur conteneur avec Bamboo:

org.Apache.maven.surefire.booter.SurefireBooterForkException: Le forked VM s'est terminé sans dire au revoir correctement

Après de nombreuses heures de recherche, je l'ai corrigé. 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 commande mvn clean package pour les applications Java dans les conteneurs de menu fixe. 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 pour Junit5 et remplacer le plug-in Surefire dans votre pom.xml.

Exclusion d'insertion 1.Inside Spring Boot Dependance:

<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érer 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. 

2
ripreal

Définir ceci dans pom.xml a fonctionné pour moi . Mais vous devriez vérifier la documentation pour d’autres solutions 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>
2
Gryffe

Utilisation de maven surefire 2.21.0 J'ai résolu le problème en modifiant la valeur de l'option reuseForks de true en 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 à:

<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>
1
Csaki Istvan

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

Environment : La construction a échoué dans l'environnement gitlab ci, en l'exécutant à l'intérieur d'un conteneur de menu fixe.

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

Cause : SUREFIRE-1422 - surefire utilise la commande ps, qui n'était pas disponible dans l'environnement du menu fixe et qui a provoqué le "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

1
Joker

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 versions clean test fonctionnaient correctement lors du lancement à partir d’Eclipse, mais lorsqu’elles ont été lancées en ligne de commande, cette erreur s’est produite. Les constructions de CI sur CircleCI fonctionnaient bien aussi.

Ce que j’ai fait: par pure hypothèse, c’est de configurer un logback-test.xml correct et de 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 argument est que la manière dont les frameworks de journalisation sont utilisés ou configurés peut être une autre explication .

Était-ce vraiment un conflit entre log4j et logback? Ou était-ce simplement que le grand volume de journalisation produit par les tests avait débordé d'une mémoire tampon de ligne de commande? Je ne sais pas. Cela reste un mystère pour moi.

1
AbVog

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

1
Francesco Borzi

J'ai rencontré ce problème pendant que Jenkins construit sur une machine Ubuntu.

/var/log/syslog rapporté Out of memory: Kill process 19557 (Java) score 207 or sacrifice child.

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

1
Abdull

Lorsque j'ai rencontré cette erreur, cela était dû au fait que mon ulimit pour les fichiers ouverts (ulimit -n) était trop faible. Il était (en quelque sorte) réglé à seulement 256:

% ulimit -n
256

L'erreur a disparu après avoir augmenté la limite:

% ulimit -n 3072
% ulimit -n     
3072

Votre système pourrait ne pas autoriser une limite aussi élevée. Par exemple, cela se produit lorsque j'essaie d'utiliser un nombre plus élevé:

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

Ou cela pourrait être inférieur à votre limite actuelle et vous pourriez être confronté à une cause fondamentale différente.

0
erik.weathers

Dans mon cas, le problème était lié au chemin d'accès à l'espace de travail, qui était trop long. J'ai donc procédé à une refactorisation de trajectoire et cela a résolu le problème pour moi.

0
thiago-devel

J'ai aussi vécu cela - mais dans mon cas, j'avais écrit un crochet personnalisé pour le concombre 

public class MappingFormatter implements gherkin.formatter.Formatter {

...

une de mes méthodes produisait une exception de pointeur Null, ce qui provoquait la fermeture du surefire sans enregistrer l'erreur.

0
pbirnie

J'ai rencontré cette erreur après qu'une variable membre statique de ma classe de test ait appelé une méthode pour créer un objet (utilisé dans les cas de test de la classe) et que la méthode a généré 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 capture des exceptions en conséquence. Ou en initialisant l'objet dans une méthode @BeforeTest et en s'assurant qu'il est construit correctement.

0
user2812481

Cela pourrait aussi arriver en raison d'un problème totalement différent. Par exemple, dans mon cas, notre version de Jenkins échouait par intermittence lors de l'exécution de tests sans aucune raison.

J'ai passé au crible nos tests pour trouver toute occurrence de System.exit() mais il n'y en avait pas. 

Après avoir approfondi mes recherches, j'ai découvert que cela pourrait se produire à cause d'un bogue du JDK qui aurait pu causer cette régression. 

JDK-6675699

Je travaille toujours sur ce correctif dans nos versions, je reviendrai et mettrai à jour le fil.

0
SarZ

Ma résolution à ce problème était de Fermer le foutu navigateur chrome qui étouffait la mémoire de mon ordinateur ????

0
Anand Rockzz

Pour mon cas, c’était mon code qui appelait System.exit (0).

Voici l'extrait de la documentation:

Surefire ne prend pas en charge les tests ni les bibliothèques référencées appelant System.exit () à tout moment. S'ils le font, ils sont incompatibles avec Surefire et vous devriez probablement signaler un problème à la bibliothèque/au fournisseur.

0
selman

Cela fonctionnera définitivement .....

Ajouter les lignes ci-dessous dans le fichier POM et donner une construction.

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

Sous Windows (OpenJDK11, Maven 3.6.0, SUREFIRE 3.0.0-M1), j'ai la cause première:

# 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ésolus en augmentant la taille du fichier de pagination, par exemple, comme this .

0
Radoslav Ivanov

Récemment, travis a tué l'exécution d'un test (sans rien changer de relatif (et des constructions réussies sur des machines de développement!)), Donc BUILD FAILURE . L'une des causes en est une réponse):

Surefire ne prend pas en charge les tests ni les bibliothèques référencées appelant System.exit () `

(puisque la classe de test s'appelle en effet System.exit(-1)).

  1. Utiliser plutôt une simple instruction return est utile. 

  2. Pour rendre Travis heureux à nouveau, je devais également ajouter les paramètres surefire (<argLine>) fournis par @xiaohuo. (aussi, j'ai dû enlever -XX:MaxPermSize=256m pour pouvoir construire sur l'un de mes ordinateurs de bureau)

Faire seulement un} des deux choses n'a pas fonctionné.

Pour plus d'informations, lisez Quand devons-nous appeler System.exit en Java .

0
dr0i

Dans mon cas, j'ai oublié d'ajouter la dépendance dans le pom:

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

Assurez-vous simplement que vous choisissez la bonne version (à ce jour, la dernière version est la 1.8.9)

0
Martin Zehle

Vous pouvez définir les options Java

SET Java_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

0
abhimanyu

essayé tout ce qui précède, 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>

0
Yuebing Cao

La machine virtuelle Java utilisée dans le test manque de mémoire. La solution consisterait soit à désactiver le forking d’une machine virtuelle Java et à exécuter les tests sur la machine virtuelle principale afin de s’assurer que vous disposez de suffisamment de mémoire, soit à passer des arguments pour augmenter la mémoire de la machine virtuelle Java fourchue.

Découvrez la solution dans cette réponse

0
Muji

J'ai également rencontré ce problème sous 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 une machine virtuelle restante surefire-forked-JVM. Les sorties de journal vers le terminal Eclipse IDE ne montrent pas le problème sous-jacent qui était adresse déjà utilisée. Le message du journal n'était 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. En passant, j'utilise le plugin surefire version 2.21.0 sans aucun 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).

0
Gregg Leichtman

J'ai rencontré le même problème lorsque j'essayais de compiler un projet maven défini sur 1.7 sur un environnement Windows 10 exécutant Java = 1.8. 

Je l'ai résolu en changeant la version Java de 1.7 à 1.8 comme indiqué ci-dessous.

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

Cela peut être dû à une mémoire insuffisante. Assurez-vous qu'aucune application ne s'exécute en arrière-plan lors de l'exécution de MVN. Dans mon cas, Firefox fonctionnait en arrière-plan avec une utilisation de mémoire importante. 

0
Sidath Bhanuka Randeniya