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

189

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
ein Stapel
quelle
7
Führen Sie Maven erneut mit -e und -X aus, wie in der Ausgabe angegeben, und fügen Sie ein, was es Ihnen gibt. Erstellen Sie auch Ihren eigenen Code oder eine vorhandene Bibliothek? Wenn Sie Ihren eigenen Code erstellen, rufen Sie System.exit (int) irgendwo auf? Wenn Sie eine vorhandene Bibliothek erstellen, woher haben Sie die Quelle?
Dylon
@Dylon Edwards: Es ist ein vorhandener Quellcode, ein OpenDayLight-Projekt für die SDN-Implementierung.
Astack
Ein aktuelles Szenario, das das Problem reproduziert, war das Ausführen von Testsuiten aus XML-Dateien. Wenn eine XML-Datei eine Klasse definiert, die nicht mehr vorhanden ist oder auf den alten, vollständig qualifizierten Namen einer Klasse verweist, der verschoben wurde, kann die JVM die Klasse nicht laden. Dies führt zu der seltsamen Nachricht, die Sie beobachtet haben. Wenn Sie sich einen Stack-Trace genauer ansehen, können Sie solche Probleme identifizieren. In diesem Fall müssen Sie die Schalter -e oder -X nicht übergeben.
Ivaylo Slavov
@astack Was war die Lösung dafür? Könntest du bitte eine Antwort markieren oder deine eigene schreiben?
Naman

Antworten:

121

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>
Xiaohuo
quelle
7
+1 Ich habe dieses Snippet wörtlich verwendet und es hat mein Problem mit Travis-CI behoben. Wir haben dies auf keiner der Workstations unserer Entwickler erhalten.
StartupGuy
7
Oben wurde das Problem für mich nicht behoben. Dieses Problem kann auftreten, wenn eine der Abhängigkeiten (jar usw.) in .m2beschädigt ist. Löschen Sie ~ / .m2 / repository rm -rf ~/.m2/repositoryund mvn installlösen Sie es dann für mich.
ch4nd4n
2
Kopiere und füge dies in meine POM-Datei ein und es funktionierte wie ein Zauber, danke
Flaom
6
OpenJDK 64-Bit-Server-VM-Warnung: Option MaxPermSize = 256m wird ignoriert; Unterstützung wurde in 8.0
Julien
2
Könnte jemand erklären, was es tatsächlich tut und welche Auswirkungen es hat?
Borgmater
71

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
Mikhail
quelle
Die zu langen Protokolle waren auch für mich das Problem! Das Umleiten zu einer Protokolldatei hat nicht geholfen. Das Ändern einiger der häufigsten Protokollierungsanweisungen, von Info zu Debug, löste das Problem
RvPr
7
zu viel Protokollierung war in meinem Fall ein echtes Problem !!
Changwon Choe
1
Vergessen Sie auch nicht den Fehlerstrom: mvn clean test 2> err.txt 1> out.txt oder mvn clean test> out.txt 2> & 1 oder mvn clean test 2> & 1 | tee out.txt Während der Umleitung können Sie die Ausgabe in einer anderen Konsole mit weniger + F out.txt
radzimir
1
Für mich hat der Wechsel von Windows Cmd zur Intellij-Konsole das Problem gelöst.
Brokkoli
3
Das Umleiten in eine Protokolldatei behebt dieses Problem.
Horizont7
39

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>
Michał Orliński
quelle
Für mich hat diese Kombination funktioniert, danke: <plugin> <groupId> org.apache.maven.plugins </ groupId> <artifactId> Maven-Surefire-Plugin </ Artefakt-ID> <Version> 2.22.1 </ Version> <Konfiguration> < testFailureIgnore> true </ testFailureIgnore> </ configuration> </ plugin>
Abhishek
Vielen Dank für diese, mit maven:3.6.0-jdk-10Docker Bild und ein Upgrade auf Version 3.0.0-M3von maven-surefire-pluginals auch für mich gelöst.
Danialk
17
In Bezug auf Lösung 3: Können wir wirklich sagen, dass das Ignorieren von Testfehlern eine Lösung ist? Was bringt es, Tests durchzuführen, wenn das Ergebnis bedeutungslos ist?
Ulukai
Ich habe gerade das Maven-Surefire-Plugin auf 2.22.2 aktualisiert und funktioniert einwandfrei!
Krzysztof Walczewski
Jep! Das Upgrade von tofire auf v2.22.2 hat es auch für mich gelöst. Vielen Dank!
Migs
32

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
Majikman
quelle
1
Vielen Dank. Der Wechsel von 1.8.0_161-b12 zu 11.0.1 + 13 hat in unserem Fall geholfen.
Karussell
1
Dies ist genau das Problem, mit dem ich bei meinen Jenkins konfrontiert war, und es ist jetzt gelöst. Vielen Dank.
Vighnesh Pai
OP hatte eine andere Fehlermeldung:The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
PetroCliff
1
@PetroCliff Ich habe bestätigt, dass dies der Fehler war, den ich auch bekam, als ich sagte "Wir haben bemerkt, dass unsere Builds in Jenkins mit diesem Fehler kaputt gegangen sind ". Ich fuhr dann fort zu erklären, dass der Fehler irreführend war und dass der tatsächliche Fehler darin lag surefire-reports.
Majikman
25

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.

Agudian
quelle
9

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>
Mahmoud sagte
quelle
1
Ein einfaches Hinzufügen einer neueren Version 3.0.0-M1 (zum Beispiel) hat das Problem gelöst.
Galigator
6

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.

Vollständige Plugin-Konfiguration:
        <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.

Javabeangrinder
quelle
6

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)

Andrejro
quelle
6

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>
Loi Cao
quelle
1
Dies ist derjenige, der es für mich behoben hat. Ich habe Maven via Artifactory auf einem Docker-Image erstellt, das sich in der Warteschlange von Gitlab befindet. Es war schwierig, ein repräsentatives Setup zum Laufen zu bringen, und nachdem viele Optionen für todsichere Einstellungen ausprobiert wurden, wurde dieses Problem mit Version 2.22.0 behoben.
Richard Bown
1
Ich muss diese Option für jeden Maven-Job in Gitlab CI hinzufügen und habe keine Ahnung warum.
Cljk
5

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.

Chad Van De Hey
quelle
5

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

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

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.

Naresh Singh
quelle
4

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.

AbVog
quelle
Upvoting, weil dies das Problem wirklich lösen / vermeiden / umgehen kann. Ich verwende slf4j und sl4j-simple unter Windows und die träge Ausgabe hat mich auch in diese Richtung gelenkt. Festlegen von System.setProperty (SimpleLogger.DEFAULT_LOG_LEVEL_KEY, "warn"); hat den Trick gemacht. Das Downgrade des Maven-Surefire-Plugins auf 2.18.1 funktionierte ebenfalls.
Marcus
4

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>

Max Vorontsov
quelle
Dies war in der Tat das Problem, das ich mit meinem Projekt hatte. Schade, dass diese Antwort nicht so sichtbar ist ...
OmriYaHoo
4

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>
Alex
quelle
Hmm, das hilft tatsächlich!
Zhen Zhang
Ja, v2.22.2hat ein Problem mit maven:3.6-jdk-8-alpine. So nervig!
KimchiMan
3

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.

ripreal
quelle
2

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

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

Muji
quelle
1

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.

Abdull
quelle
1

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

Anand Rockzz
quelle
1

Sie können Java-Optionen festlegen

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

abhimanyu
quelle
1

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 .

Radoslav Ivanov
quelle
Unter Linux (4.4.0-145-generic, amd64) wurde für einen Jenkins-Job von Oracle JRE 8 in AdoptOpenJDK_8u202b08 geändert, und es wurde der Fehler "fork" ausgegeben: - "Ausführungsstandardtest des Ziels org.apache.maven.plugins : maven-surefire-plugin: 2.19.1: Test fehlgeschlagen: Die gegabelte VM wurde beendet, ohne sich ordnungsgemäß zu verabschieden. VM-Absturz oder System.exit aufgerufen? " - Zurück zu Oracle JRE geändert und der Fehler gestoppt. Dies ist der einzige Job (unser von ungefähr 300), der dieses Problem hat. Glücklicherweise handelt es sich nur um ein internes Projekt, nicht um ein vom Kunden zu lieferndes Projekt. Wir können es auf Sun / Oracle JRE behalten.
Robert
1

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>

Yuebing Cao
quelle
Diese genaue Plugin-Version hat mich begeistert. Meine Konfiguration ist übrigens: 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

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

Francesco Borzi
quelle
1

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

Joker
quelle
1

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

Gregg Leichtman
quelle
1

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.

teja
quelle
0

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.

user2812481
quelle
0

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.

thiago-devel
quelle
War das auf einer Windows-Maschine?
Hithwen
Ja, es läuft unter Windows.
Thiago-Devel
Wie haben Sie das gefunden?
Dzieciou