Die gegabelte VM wurde beendet, ohne sich ordnungsgemäß zu verabschieden. VM-Absturz oder System.exit aufgerufen

Bitte helfen Sie mir, dieses Problem zu lösen. Ich verstehe nicht genau, was der Fehler im Protokoll bedeutet.

[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

Ich hatte das gleiche Problem und löste es durch Hinzufügen von:

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

Das gesamte Plugin-Element ist:

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

In meinem Fall hing das Problem mit einer zu langen Protokollausgabe in die IntelliJ IDEA-Konsole (OS Windows 10) zusammen.

Befehl:

mvn clean install

Dieser Befehl hat das Problem für mich gelöst:

mvn clean install > log-file.log

Ich habe ein sehr ähnliches Problem ( Maven Build und Maven-Failsafe-Plugin - Die gegabelte VM wurde beendet, ohne sich richtig zu verabschieden ) und drei Lösungen gefunden, die für mich funktionieren:

Problembeschreibung

Problem ist mit Maven Plugin Maven-Surefire-Plugin nur in Version 2.20.1 und 2.21.0. Ich habe es überprüft und Sie verwenden Version 2.20.1.

Lösung 1

Aktualisieren Sie die Plugin-Version auf 2.22.0 . In pom.xml hinzufügen :

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

Lösung 2

Downgrade der Plugin-Version auf 2.20 . In pom.xml hinzufügen :

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

Lösung 3

Verwenden Sie die Plugin-Konfiguration testFailureIgnore . In pom.xml hinzufügen :

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

Ab heute (30.10.2008) haben wir festgestellt, dass unsere Builds in Jenkins mit diesem Fehler kaputt gegangen sind.

Der Fehler ist etwas irreführend und muss anhand der Ausgabe des Dumps überprüft werden target/surefire-reports/ , um die folgende Fehlermeldung anzuzeigen:

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

Das führte mich zu dem folgenden SO-Beitrag, in dem ein möglicher Fehler in OpenJDK 181 erwähnt wird: Maven Surefire konnte die ForkedBooter-Klasse nicht finden

Beide Korrekturen in diesem Beitrag lösen mein Problem. Um genau zu sein, habe ich eine der folgenden Methoden verwendet:

1. Wechsel vom Gebäude im Docker-Container maven:3.5.4-jdk-8zumaven:3.5.4-jdk-8-alpine
2. Überschreiben des Klassenladers von Spring Boot, der hier beschrieben wird: https://stackoverflow.com/a/50661649/1228408

Dieser Teil der Surefire-FAQ könnte Ihnen helfen:

Surefire schlägt mit der Meldung "Die gegabelte VM wurde beendet, ohne sich ordnungsgemäß zu verabschieden" fehl.

Surefire unterstützt zu keinem Zeitpunkt Tests oder Bibliotheken, auf die verwiesen wird, die System.exit () aufrufen. Wenn sie dies tun, sind sie nicht mit todsicher kompatibel und Sie sollten wahrscheinlich ein Problem bei der Bibliothek / dem Anbieter einreichen. Alternativ kann die gegabelte VM auch aus einer Reihe von Gründen abstürzen, wodurch dieses Problem ebenfalls auftreten kann. Suchen Sie nach den klassischen "hs_err *" - Dateien, die auf VM-Abstürze hinweisen, oder überprüfen Sie die Protokollausgabe von Maven, wenn die Tests ausgeführt werden. Einige "außergewöhnliche" Ausgaben von abstürzenden Prozessen werden möglicherweise in die Konsole / das Protokoll geschrieben. Wenn dies in einer CI-Umgebung geschieht und erst nach einiger Zeit ausgeführt wird, besteht eine gute Chance, dass Ihre Testsuite eine Ressource auf Betriebssystemebene verliert, die die Situation bei jedem Lauf verschlimmert. Regelmäßige Tools zur Überwachung auf Betriebssystemebene können Ihnen Hinweise geben.

War gerade vor dem gleichen Problem, Java 8 auf Ubuntu

dann stieß auf https://stackoverflow.com/a/53016532/1676516

Es scheint ein neuer Fehler in der todsicheren Plugin-Version 2.22.1 mit Java 8 https://issues.apache.org/jira/browse/SUREFIRE-1588 zu sein

Befolgen Sie die vorgeschlagene Problemumgehung durch die lokalen MVN-Einstellungen ~/.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>

Ich hatte heute das gleiche Problem und für mich wurde das eigentliche Problem weiter oben im Protokoll mit Nachricht gemeldet Cannot use a threadCount parameter less than 1; 1 > 0 . Beim Hinzufügen <threadCount>1</threadCount>der todsicheren Plugin-Konfiguration verschwand der andere Fehler.

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

... und ja, ich verwende aus Gründen der Abwärtskompatibilität sowohl junit als auch testng in diesem Testframework.

Habe ähnliches Problem beim Ausführen von mvn Befehl mit Jacoco Plugin auf 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?

In JDK https://bugs.openjdk.java.net/browse/JDK-8081379 ist ein Fehler aufgetreten

Die Lösung bestand darin, mvn clean install mit param -XX: -UseLoopPredicate auszuführen

Oder machen Sie einfach ein Update für JDK (ich denke, eine neuere Nebenversion funktioniert)

Das Deaktivieren von useSystemClassLoader des Maven-Surefile-Plugins sollte helfen

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

Wenn jemand ein benutzerdefiniertes argLine-Argument enthält, müssen Sie es erneut prüfen, da es wahrscheinlich die Ursache für Ihre Probleme mit der Speicherzuweisung ist.

Zum Beispiel (ich hatte früher):

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

Jetzt verwende ich fest spezifizierte Werte:

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

Aus irgendeinem Grund fordern Anwendungen, die in Surefire integriert sind, wie z. B. Jacoco, nicht genügend Speicher an, um mit den Tests, die zum Zeitpunkt der Erstellung durchgeführt werden, koexistieren zu können.

Ich bin auch in einem Jenkins Docker-Container auf dieses Problem gestoßen (versuchte es mit Jenkins: lts, ​​jenkins, jenkins: slim und jenkins: slim-lts. Ich wollte nicht alle Repositorys durchgehen und den POM für jedes Projekt aktualisieren, also habe ich habe gerade den Befehl disableClassPathURLCheck zum Befehlszeilenaufruf maven hinzugefügt:

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

Mit maven surefire 2.21.0 habe ich das Problem behoben, bei dem der reuseForksOptionswert von true in false geändert wurde :

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

Mein gesamter Konfigurationsabschnitt im Build sah folgendermaßen aus:

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

Sie müssen überprüfen, ob Ihr Computer 64-Bit oder 32-Bit ist. Wenn Ihr Computer 32-Bit ist, sollte Ihr Speicherargument 4096 nicht überschreiten, auch wenn es unter 4 GB liegen sollte. Wenn Ihr Computer jedoch 64-Bit ist, installieren Sie Java 64-Bit und geben Sie JAVA_HOME in mvn.bat an, was auf die Java-64-Bit-Installation verweist.

Ich habe einen Fall getroffen, in dem keine der Antworten das Problem gelöst hat. Es war mit einer Legacy-Anwendung, die zufällig log4j und SLF4J / logback verwendet.

Die vorherige Situation: clean testBuilds liefen beim Start in Eclipse einwandfrei, aber beim Start in der Befehlszeile trat dieser Fehler auf. CI baut auf CircleCI auf und lief auch einwandfrei.

Was ich getan habe: Aus reiner Vermutung heraus ist es, eine richtige zu konfigurieren logback-test.xml und die Ausführlichkeit der Protokollierung herabzusetzen. Siehe da, ich habe diesen Fehler nicht mehr festgestellt und kann jetzt das Projekt (sowie das Modul, in dem dieser Fehler aufgetreten ist) über die Befehlszeile erstellen.

Mein Punkt ist, dass die Art und Weise, wie die Protokollierungsframeworks verwendet oder konfiguriert werden, eine andere Erklärung sein kann .

War es wirklich ein Konflikt zwischen log4j und logback? Oder war es nur so, dass das hohe Protokollierungsvolumen, das durch die Tests erzeugt wurde, einen Befehlszeilenpuffer überlief? Ich weiß es nicht. Es bleibt mir ein Rätsel.

Nach dem Upgrade auf Java 12 hatte ich ein ähnliches Problem. Für mich bestand die Lösung darin, die Jacoco-Version zu aktualisieren <jacoco.version>0.8.3</jacoco.version>

Version 2.22.2 hat echte Probleme mit gegabelten JVMs. Verwenden Sie Version 2.20 - es funktioniert wie ein Zauber!

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

Ich habe mich kürzlich an diesen Fehler gehalten, als ich meine Anwendungen für Containergläser mit Bamboo erstellt habe:

org.apache.maven.surefire.booter.SurefireBooterForkException: Die gegabelte VM wurde beendet, ohne sich ordnungsgemäß zu verabschieden

Nach vielen Stunden der Recherche habe ich es behoben. Und ich dachte, es wäre nützlich, meine Lösung hier zu teilen.

Der Fehler tritt also jedes Mal auf, wenn der mvn clean packageBefehl bamboo run für Java-Anwendungen in den Docker-Containern ausführt. Ich bin kein Maven-Experte, aber das Problem lag in den Surefire- und Junit4-Plugins, die im Spring-Boot als Maven-Abhängigkeit enthalten waren.

Um dies zu beheben, müssen Sie Junit4 für Junit5 ersetzen und das Surefire-Plugin in Ihnen überschreiben pom.xml .

1.Inside Spring Boot Dependency Insert Ausschluss:

<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. Fügen Sie neue Junit5-Abhängigkeiten hinzu:

<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. Fügen Sie ein neues Plugin in den Plugin-Bereich ein

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

Das sollte ausreichen, um Bambusbauten zu reparieren. Vergessen Sie nicht, auch alle Junit4-Tests so zu transformieren, dass sie Junit5 unterstützen.

Das Einstellen in pom.xml hat bei mir funktioniert. Sie sollten jedoch die Dokumentation auf andere Problemumgehungen überprüfen: 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>

Die im Test verwendete gegabelte JVM hat nicht genügend Speicher. Die Lösung wäre, entweder das Gabeln einer JVM zu deaktivieren und die Tests auf der Haupt-JVM auszuführen, um sicherzustellen, dass Sie über ausreichend Speicher verfügen, oder Argumente zu übergeben, um den Speicher der gegabelten JVM zu erhöhen

Überprüfen Sie die Lösung in dieser Antwort

Ich bin auf dieses Problem gestoßen, als Jenkins auf einem Ubuntu-Computer erstellt.

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

Ich habe der Ubuntu-Maschine daher mehr Swap-Platz gegeben . Seitdem ist das Problem weg.

Meine Lösung für dieses Problem war zu schließen , das verdammte Chrome - Browser , die meine Computerspeicher würgen 🙄

Sie können Java-Optionen festlegen

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

Unter Windows (OpenJDK11, Maven 3.6.0, SUREFIRE 3.0.0-M1) habe ich diese Grundursache:

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

und durch Erhöhen der Größe der Auslagerungsdatei, z . B. auf diese Weise, behoben .

alles oben versucht, hat nicht funktioniert. Die folgende Lösung funktioniert für mich:

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

Ich hatte das gleiche Problem und löste es mit Java 8 von Oracle anstelle von Java 10 von Openjdk

Ich habe alle bereitgestellten Lösungen ausprobiert (Forking, Systemloader, mehr Speicher usw.), nichts hat funktioniert.

Umgebung : Der Build ist in der gitlab ci-Umgebung fehlgeschlagen, und der Build wurde in einem Docker-Container ausgeführt.

Lösung : Wir haben in Version 2.20.1 surefireplugin verwendet und ein Upgrade auf 2.21.0 oder höher (wir haben 2.22.1 verwendet) hat das Problem behoben.

Ursache : SUREFIRE-1422 - safefire verwendet den Befehlps , der in der Docker-Umgebung nicht verfügbar war und zum "Absturz" führte. Dieses Problem wurde in 2.21.0 oder höher behoben.

Dank dieser Antwort von einer anderen Frage: https://stackoverflow.com/a/50568662/2970422

Dieses Problem trat auch unter MacOS beim Remote-Debuggen des Selenium-Testcodes auf Port 5005 auf. Das Problem wurde durch eine übrig gebliebene todsichere JVM verursacht, die weiterhin ausgeführt wurde. Die Protokollausgabe an das Eclipse IDE-Terminal zeigte nicht das zugrunde liegende Problem an, bei dem es sich um eine bereits verwendete Adresse handelte . Die Protokollmeldung wurde nur angezeigt, als ich denselben Befehl in einem MacOS-Terminal ausführte, den Eclipse tatsächlich ausführen wollte:

/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

Das Problem wurde behoben, indem die unerwünschte JVM-Instanz getötet wurde (suchen Sie im Aktivitätsmonitor nach einem Java-Prozessnamen). Übrigens verwende ich das todsichere Plugin Version 2.21.0 ohne Probleme mit open jdk 8 (v1.8.0_212). Beachten Sie, dass alle Pfade spezifisch für Ihre Build-Umgebung und möglicherweise den Port sind (Adresse = 5005).

Ich hatte das gleiche Problem, als ich Unit-Tests mit dem Maven-Test durchführte. Versucht, die todsicheren Versionen zu ändern, aber es funktioniert nicht. Schließlich gelang es, wie folgt zu lösen: FRÜHER: (als das Problem auftrat): Javac ist von JDK 1.8 Java zeigte auf den Java-Bin von JDK 1.11 AKTUELL: (als das Problem behoben wurde): Sowohl Java als auch Java zeigen auf die Behälter von JDK 1.8

Grüße Teja.

Dieser Fehler trat auf, nachdem eine statische Elementvariable in meiner Testklasse eine Methode zum Erstellen eines Objekts aufgerufen hatte (die in Testfällen in der gesamten Klasse verwendet wurde) und die Methode eine Ausnahme verursachte.

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

Einige Korrekturen umfassen das Neuerstellen des Objekts in jedem Testfall und das entsprechende Abfangen von Ausnahmen. Oder indem Sie das Objekt in einer @ BeforeTest-Methode initialisieren und sicherstellen, dass es ordnungsgemäß erstellt wurde.

In meinem Fall bezog sich das Problem auf den zu langen Arbeitsbereichspfad. Also habe ich ein Path Refactoring durchgeführt und das Problem für mich gelöst.