Rozwidlona VM zakończyła się bez pożegnania. Awaria maszyny wirtualnej lub wywołanie System.exit

Pomóż mi rozwiązać ten problem. Nie do końca rozumiem, co oznacza błąd w dzienniku.

[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

Miałem ten sam problem i rozwiązałem go dodając:

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

Cały element wtyczki to:

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

W moim przypadku problem związany był ze zbyt długim wyjściem dziennika do konsoli IntelliJ IDEA (system operacyjny Windows 10).

Komenda:

mvn clean install

To polecenie rozwiązało problem:

mvn clean install > log-file.log

Mam bardzo podobny problem ( kompilacja Maven i wtyczka maven-failafe-Rozwidlona maszyna wirtualna zakończyła się bez właściwego pożegnania ) i znalazłem trzy rozwiązania, które działają dla mnie:

Opis problemu

Problem dotyczy wtyczki maven Wtyczka maven- surefire tylko w wersji 2.20.1 i 2.21.0. Sprawdziłem i używasz wersji 2.20.1.

Rozwiązanie 1

Zaktualizuj wersję wtyczki do 2.22.0 . Dodaj pom.xml :

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

Rozwiązanie 2

Zmień wersję wtyczki na 2.20 . Dodaj pom.xml :

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

Rozwiązanie 3

Skorzystaj z testu konfiguracji wtyczki FailureIgnore . Dodaj pom.xml :

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

Na dzień dzisiejszy (30.10.2018) zauważyliśmy, że nasze kompilacje psują się w Jenkins z tym błędem.

Błąd jest nieco mylący i wymagał spojrzenia na wynik zrzutu, target/surefire-reports/ aby zobaczyć następujący komunikat o błędzie:

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

Doprowadziło mnie to do następującego postu SO, w którym wspomniano o możliwym błędzie w OpenJDK 181: Maven pewnik nie mógł znaleźć klasy ForkedBooter

Każda z poprawek w tym poście rozwiązuje mój problem. Aby być konkretnym, użyłem jednego z tych:

1. Przełączanie z budynku w kontenerze dokowanym maven:3.5.4-jdk-8namaven:3.5.4-jdk-8-alpine
2. Przesłanianie modułu ładującego klasy Spring Boot szczegółowo tutaj: https://stackoverflow.com/a/50661649/1228408

Ta część FAQ Surefire może pomóc:

Surefire kończy się niepowodzeniem z komunikatem „Rozwidlona maszyna wirtualna została zakończona bez właściwego pożegnania”

Surefire nie obsługuje testów ani bibliotek, do których istnieją odwołania, wywołujących System.exit () w dowolnym momencie. Jeśli to zrobią, są niekompatybilne z surefire i prawdopodobnie powinieneś zgłosić problem z biblioteką / dostawcą. Alternatywnie rozwidlona maszyna wirtualna może również ulec awarii z wielu powodów, co może również powodować ten problem. Poszukaj klasycznych plików „hs_err *” wskazujących na awarie maszyn wirtualnych lub sprawdź dane wyjściowe dziennika uruchomionego maven podczas wykonywania testów. Niektóre „nadzwyczajne” dane wyjściowe z procesów powodujących awarie mogą zostać zrzucone do konsoli / dziennika. Jeśli dzieje się tak w środowisku CI i tylko po pewnym czasie działa, istnieje duża szansa, że ​​pakiet testowy wycieka z jakiegoś zasobu na poziomie systemu operacyjnego, co pogarsza sytuację przy każdym uruchomieniu. Zwykłe narzędzia do monitorowania na poziomie systemu operacyjnego mogą dać ci pewne wskazówki.

Właśnie miałem do czynienia z tym samym problemem, java 8 na Ubuntu

następnie natknąłem się na https://stackoverflow.com/a/53016532/1676516

Wydaje się, że to ostatni błąd we wtyczce surefire w wersji 2.22.1 z java 8 https://issues.apache.org/jira/browse/SUREFIRE-1588

postępował zgodnie z sugerowanym obejściem przez lokalne ustawienia mvn ~/.m2/settings.xml

<profiles>
    <profile>
        <id>SUREFIRE-1588</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <argLine>-Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>
        </properties>
    </profile>
</profiles>

Miałem dzisiaj ten sam problem i dla mnie prawdziwy problem został zgłoszony dalej w dzienniku z komunikatem Cannot use a threadCount parameter less than 1; 1 > 0. Podczas dodawania <threadCount>1</threadCount>w konfiguracji wtyczki surefire drugi błąd zniknął.

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

... i tak, używam zarówno junit, jak i testng w tym środowisku testowym ze względu na kompatybilność wsteczną.

Miał podobny problem podczas uruchamiania komendy mvn z wtyczką Jacoco na 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?

Wystąpił błąd w JDK https://bugs.openjdk.java.net/browse/JDK-8081379

Rozwiązaniem było uruchomienie mvn clean install z param -XX: -UseLoopPredicate

Lub po prostu zaktualizuj JDK (myślę, że działa nowa wersja pomocnicza)

Wyłącz useSystemClassLoader wtyczki maven-surefile-plug powinien pomóc

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

Jeśli ktoś dołącza niestandardowy argument argLine, należy ponownie rozważyć, ponieważ jest to prawdopodobnie przyczyną problemów z alokacją pamięci.

Na przykład (kiedyś miałem):

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

Teraz używam ściśle określonych wartości:

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

Z jakiegokolwiek powodu aplikacje integrujące się z Surefire, takie jak Jacoco, nie żądają wystarczającej ilości pamięci, aby współistnieć z testami, które mają miejsce podczas kompilacji.

Wpadłem również na ten problem w kontenerze Jenkins Docker (próbowałem jenkins: lts, ​​jenkins, jenkins: slim i jenkins: slim-lts. Nie chciałem przeglądać wszystkich repozytoriów i aktualizować pom dla każdego projektu, więc właśnie dodałem disableClassPathURLCheck do wywołania linii poleceń maven:

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

Używając maven surefire 2.21.0 Rozwiązałem problem zmiany reuseForkswartości opcji z prawdy na fałsz :

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

Cała moja sekcja konfiguracji w trakcie budowy wyglądała następująco:

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

Musisz sprawdzić, czy twój komputer jest 64-bitowy czy 32-bitowy. Jeśli twój komputer jest 32-bitowy, argument pamięci nie powinien przekraczać 4096, nawet poniżej 4 GB. ale jeśli twój komputer jest 64-bitowy, zainstaluj Java 64-bitowy i podaj JAVA_HOME w mvn.bat, które wskazują na 64-bitową instalację Java.

Spotkałem przypadek, w którym żadna z podanych odpowiedzi nie rozwiązała problemu. Było to ze starszą aplikacją, która akurat używa log4j i SLF4J / logback.

Poprzednia sytuacja: clean testkompilacje działały poprawnie po uruchomieniu z poziomu Eclipse, ale po uruchomieniu w linii poleceń wystąpił ten błąd. Kompilacje CI na CircleCI również działały dobrze.

To, co zrobiłem: z czystego zgadywania, to skonfigurowanie właściwego logback-test.xmli obniżenie szczegółowości rejestrowania. I oto, nie doświadczyłem już tego błędu i mogę teraz zbudować projekt (a także moduł, w którym ten błąd występował) z wiersza poleceń.

Chodzi mi o to, że sposób, w jaki struktury rejestrowania są używane lub konfigurowane, może być innym wyjaśnieniem .

Czy to naprawdę był konflikt między log4j a logback? A może po prostu duża ilość rejestrowania wynikająca z testów w jakiś sposób przepełniła bufor linii poleceń? Nie wiem Pozostaje mi to tajemnicą.

Podobny problem spotkałem po aktualizacji do java 12, dla mnie rozwiązaniem była aktualizacja wersji jacoco <jacoco.version>0.8.3</jacoco.version>

wersja 2.22.2 ma prawdziwe problemy z rozwidlonymi maszynami JVM. Użyj wersji 2.20 - działa jak urok!

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

Niedawno utknąłem w tym błędzie podczas tworzenia aplikacji kontenerowych w słoikach za pomocą Bamboo:

org.apache.maven.surefire.booter.SurefireBooterForkException: Rozwidlona maszyna wirtualna zakończyła się bez właściwego pożegnania

Po wielu godzinach badań naprawiłem to. Pomyślałem, że warto udostępnić tutaj moje rozwiązanie.

Tak więc błąd występuje za każdym razem, gdy mvn clean packagepolecenie uruchamiania z bambusa dla aplikacji Java w kontenerach dokowanych. Nie jestem ekspertem od Maven, ale problem tkwił w wtyczkach Surefire i Junit4 dołączonych do Spring-boot jako zależność od maven.

Aby to naprawić, musisz wymienić Junit4 na Junit5 i zastąpić wtyczkę Surefire pom.xml.

1.Wewnętrzne wyłączenie wstawki zależności rozruchu sprężynowego:

<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. Dodaj nowe zależności 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. Wstaw nową wtyczkę do sekcji wtyczek

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

To powinno wystarczyć do naprawy bambusowych kompilacji. Nie zapomnij również przekształcić wszystkich testów Junit4 na obsługę Junit5.

Ustawienie tego w pom.xml działało dla mnie. Ale należy sprawdzić dokumentację pod kątem innych obejść 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>

W rozwidlonej maszynie JVM użytej w teście zabrakło pamięci. Rozwiązaniem byłoby albo wyłączenie rozwidlania JVM i uruchomienie testów na głównej JVM, upewniając się, że masz wystarczającą pamięć, lub przekazanie argumentów w celu zwiększenia pamięci rozwidlonej JVM

Sprawdź rozwiązanie w tej odpowiedzi

Natrafiłem na ten problem podczas kompilacji Jenkinsa na maszynie Ubuntu.

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

Dlatego dałem maszynie Ubuntu więcej przestrzeni wymiany . Od tego czasu problem zniknął.

Moim rozwiązaniem tego problemu było zamknięcie przeklętej przeglądarki Chrome, która dusiła pamięć mojego komputera 🙄

Możesz ustawić opcje java

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

W systemie Windows (OpenJDK11, Maven 3.6.0, SUREFIRE 3.0.0-M1) mam tę główną przyczynę:

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

i rozwiązane przez zwiększenie rozmiaru pliku stronicowania, np . w ten sposób .

próbowałem wszystkiego powyżej, nie działało. poniższe rozwiązanie działa dla mnie:

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

Miałem ten sam problem i rozwiązałem go, używając Java 8 z Oracle zamiast Java 10 z Openjdk

Próbowałem wszystkich dostarczonych rozwiązań (rozwidlanie, ładowanie systemu, więcej pamięci itp.), Nic nie działało.

Środowisko : kompilacja nie powiodła się w środowisku gitlab ci, uruchamiając kompilację w kontenerze dokera.

Rozwiązanie : Użyliśmy surefireplugin w wersji 2.20.1 i aktualizacja do wersji 2.21.0 lub nowszej (użyliśmy wersji 2.22.1) rozwiązała ten problem.

Przyczyna : SUREFIRE-1422 - surefire używa poleceniaps , które nie było dostępne w środowisku dokera i doprowadziło do „awarii”. Ten problem został rozwiązany w wersji 2.21.0 lub nowszej.

Dzięki tej odpowiedzi z innego pytania: https://stackoverflow.com/a/50568662/2970422

Natknąłem się również na ten problem na MacOS podczas zdalnego debugowania kodu testowego Selenium na porcie 5005. Problem okazał się być spowodowany pozostawioną uruchomioną maszyną JVM surefire-forked-forked. Dane wyjściowe dziennika do terminala Eclipse IDE nie wykazały podstawowego problemu, którym był już adres . Komunikat dziennika był wyświetlany tylko wtedy, gdy uruchomiłem to samo polecenie w terminalu MacOS, które Eclipse faktycznie próbował uruchomić:

/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

Zabicie nieuczciwej instancji JVM (poszukaj nazwy procesu java w Activity Monitor) rozwiązało problem. Przy okazji używam wtyczki surefire w wersji 2.21.0 bez problemów z otwartym jdk 8 (v1.8.0_212). Zauważ, że wszystkie ścieżki będą specyficzne dla twojego środowiska kompilacji i ewentualnie portu (adres = 5005).

Napotkałem ten sam problem podczas uruchamiania testów jednostkowych za pomocą testu maven. Próbowałem zmienić wersje surefire, ale to nie działa. W końcu udało się rozwiązać w następujący sposób: WCZEŚNIEJ: (gdy problem się pojawiał): javac pochodzi z jdk 1.8 java wskazuje na bin java z jdk 1.11 CURRENT: (kiedy problem został rozwiązany): zarówno javac, jak i java wskazują pojemniki z jdk 1.8

Pozdrawiam Teja.

Wystąpił ten błąd po tym, jak statyczna zmienna składowa w mojej klasie testowej wywołała metodę utworzenia obiektu (która była używana w testowych przypadkach w całej klasie), a metoda spowodowała wyjątek.

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

Niektóre poprawki obejmują odtworzenie obiektu wewnątrz każdego przypadku testowego i odpowiednie wychwycenie wyjątków. Lub poprzez zainicjowanie obiektu w metodzie @BeforeTest i upewnienie się, że jest on poprawnie zbudowany.

W moim przypadku problem dotyczył zbyt długiej ścieżki obszaru roboczego. Więc zrobiłem refaktoryzację ścieżki i to rozwiązało problem.