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

192

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
stos
źródło
7
Uruchom ponownie Maven z -e i -X, jak sugeruje wyjście, i wklej to, co daje. Czy budujesz własny kod lub istniejącą bibliotekę? Jeśli budujesz swój własny kod, czy wywołujesz System.exit (int) gdziekolwiek? Jeśli budujesz istniejącą bibliotekę, skąd masz źródło?
Dylon
@Dylon Edwards: Jest to istniejący kod źródłowy, projekt OpenDayLight do implementacji SDN.
astack
Niedawny scenariusz, w którym odtworzyłem ten problem, polegał na uruchomieniu zestawów testowych z plików XML. W przypadku, gdy plik xml definiuje klasę, która już nie istnieje lub odnosi się do starej, w pełni kwalifikowanej nazwy klasy, która została przeniesiona, wówczas JVM nie ładuje klasy. Powoduje to dziwny komunikat, który zaobserwowałeś. Przybliżenie się do dowolnego śledzenia stosu może pomóc w zidentyfikowaniu takich problemów, w tym przypadku nie trzeba przekazywać przełączników -e lub -X.
Ivaylo Slavov
@astack, co okazało się rozwiązaniem tego? czy mógłbyś zaznaczyć odpowiedź lub napisać własną?
Naman

Odpowiedzi:

122

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>
xiaohuo
źródło
7
+1 Użyłem tego fragmentu, dosłownie, i naprawiłem mój problem z Travis-CI. Nie dostaliśmy tego na żadnej ze stacji roboczych naszego programisty.
StartupGuy
7
Powyższe nie rozwiązało problemu dla mnie. Ten problem może wystąpić, gdy jedna z zależności (jar itp.) .m2Jest uszkodzona. Usuwanie ~ / .m2 / repozytorium, rm -rf ~/.m2/repositorya następnie mvn installrozwiązanie dla mnie.
ch4nd4n
2
Skopiuj i wklej to do mojego pliku pom, a zadziałało to jak urok, dzięki
Flaom,
8
Ostrzeżenie dla 64-bitowego serwera OpenJDK VM: ignorowanie opcji MaxPermSize = 256m; wsparcie zostało usunięte w 8.0
Julien
2
Czy ktoś mógłby wyjaśnić, co to właściwie robi i jakie ma efekty?
borgmater,
72

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
Michaił
źródło
Zbyt długie kłody również stanowiły dla mnie problem! Przekierowanie do pliku dziennika nie pomogło. Zmiana niektórych najczęstszych instrukcji rejestrowania, z informacji na debugowanie, rozwiązała problem
RvPr
7
zbyt dużo logowania było prawdziwym problemem w moim przypadku !!
Changwon Choe,
1
Nie zapomnij też o strumieniu błędów: mvn clean test 2> err.txt 1> out.txt lub mvn clean test> out.txt 2> & 1 lub mvn clean test 2> & 1 | tee out.txt Podczas przekierowywania możesz oglądać dane wyjściowe na innej konsoli za pomocą mniej + F out.txt
radzimir
1
Dla mnie przejście z Windows cmd na konsolę Intellij rozwiązało to.
Brokuły
3
Rzeczywiście przekierowanie do pliku dziennika rozwiązuje ten problem.
horizon7
41

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>
Michał Orliński
źródło
Dla mnie ta kombinacja działała dzięki: <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-surefire-plugin </artifactId> <version> 2.22.1 </version> <configuration> < testFailureIgnore> true </testFailureIgnore> </configuration> </plugin>
Abhishek
Dzięki za to, wykorzystujące maven:3.6.0-jdk-10Docker obraz i uaktualnienie do wersji 3.0.0-M3z maven-surefire-pluginrozwiązane dla mnie również.
danialk
20
W odniesieniu do rozwiązania 3: Czy naprawdę możemy powiedzieć, że ignorowanie błędów testu jest rozwiązaniem? Po co przeprowadzać testy, jeśli ich wynik nie ma znaczenia?
Ulukai
Właśnie zaktualizowałem wtyczkę maven-surefire-plugin do 2.22.2 i działa dobrze!
Krzysztof Walczewski,
Tak! Aktualizacja do wersji 2.22 programu surefire również dla mnie rozwiązała. Dzięki!
Migs,
32

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
majikman
źródło
1
Dzięki. W naszym przypadku pomogło przejście z wersji 1.8.0_161-b12 na wersję 11.0.1 + 13.
Karussell
1
To jest dokładnie problem, z którym miałem do czynienia na moim Jenkinsie i został rozwiązany teraz. Dzięki.
Vighnesh Pai
OP otrzymał kolejny komunikat o błędzie:The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
PetroCliff
1
@PetroCliff Przyznałem, że to był błąd, który pojawiał się, gdy powiedziałem „zauważyliśmy, że nasze kompilacje psują się w Jenkins z tym błędem ”. Następnie przystąpiłem do wyjaśniania, że ​​błąd wprowadzał w błąd i że rzeczywiście występował błąd surefire-reports.
majikman
25

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.

agudian
źródło
9

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>
Mahmoud powiedział
źródło
1
Prosty dodatek nowszej wersji 3.0.0-M1 (na przykład) rozwiązał problem.
Galigator
6

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ął.

Pełna konfiguracja wtyczki:
        <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ą.

javabeangrinder
źródło
6

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)

andreyro
źródło
6

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>
Loi Cao
źródło
1
To ten, który to naprawił dla mnie. Budowałem maven za pomocą artefaktów na obrazie dokera w kolejce od gitlaba. Trudno było uruchomić reprezentatywną konfigurację i po wypróbowaniu wielu opcji ustawień surefire ten naprawił ją w wersji 2.22.0.
Richard Bown
1
muszę dodać tę opcję do każdego zadania maven w Gitlab CI i nie mam pojęcia, dlaczego.
cljk
5

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.

Chad Van De Hey
źródło
5

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"
Kevin Dubois
źródło
5

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>
Csaki Istvan
źródło
4

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.

Naresh Singh
źródło
4

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

AbVog
źródło
Upvoting, ponieważ może to naprawdę rozwiązać / uniknąć / ominąć problem. Używam slf4j i sl4j-simple w systemie Windows, a powolny wynik skierował mnie również w tym kierunku. Ustawienie System.setProperty (SimpleLogger.DEFAULT_LOG_LEVEL_KEY, „warn”); wykonał lewę. Działa również obniżenie wtyczki maven-surefire do 2.18.1.
Marcus
4

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>

Max Woroncowa
źródło
To był rzeczywiście problem, który miałem z moim projektem. Szkoda, że ​​ta odpowiedź nie jest aż tak widoczna ...
OmriYaHoo
4

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>
Alex
źródło
Hmm, to naprawdę pomaga!
Zhen Zhang
Tak, v2.22.2ma problem z maven:3.6-jdk-8-alpine. Tak denerwujące!
KimchiMan
3

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.

ripreal
źródło
2

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>
Gryffe
źródło
2

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

Muji
źródło
1

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ął.

Abdull
źródło
1

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

Anand Rockzz
źródło
1

Możesz ustawić opcje java

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

abhimanyu
źródło
1

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 .

Radosław Iwanow
źródło
W systemie Linux (4.4.0-145-generic, amd64) zmieniono z Oracle JRE 8 na AdoptOpenJDK_8u202b08 dla zadania Jenkins i zaczęto produkować błąd „fork”: - „Domyślny test wykonania org.apache.maven.plugins domyślnego wykonania” : maven-surefire-plugin: 2.19.1: test nie powiódł się: Rozwidlona maszyna wirtualna zakończyła się bez właściwego pożegnania. Awaria maszyny wirtualnej lub wywołanie System.exit? ” - Zmieniono z powrotem na Oracle JRE i błąd ustał. To jedyna praca (nasza z grubsza około 300), która ma ten problem. Na szczęście jest to tylko wewnętrzny projekt, a nie klient dostarczalny, co możemy zachować na Sun / Oracle JRE.
Robert
1

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>

Yuebing Cao
źródło
Ta dokładna wersja wtyczki mnie zaskoczyła. 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"
Nawiasem
1

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

Francesco Borzi
źródło
1

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

Żartowniś
źródło
1

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

Gregg Leichtman
źródło
1

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.

teja
źródło
0

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.

użytkownik 2812481
źródło
0

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.

thiago-devel
źródło
Czy to na maszynie z systemem Windows?
od
Tak, działa w systemie Windows.
thiago-devel
Jak to znalazłeś?
dzieciou