Роздвоєний VM припинився, не попрощавшись належним чином. Збій VM або System.exit викликано

Будь ласка, допоможіть мені вирішити це питання. Я точно не розумію, що означає помилка в журналі.

[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

У мене була та сама проблема, і я вирішив, додавши:

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

Весь елемент плагіна:

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

У моєму випадку проблема стосувалася занадто довгого виведення журналу на консоль IntelliJ IDEA (ОС Windows 10).

Команда:

mvn clean install

Ця команда вирішила мені проблему:

mvn clean install > log-file.log

У мене дуже схожа проблема ( Maven build та maven-failsafe-plugin - роздвоєний VM припинився, не попрощавшись належним чином ) і знайшов три рішення, які працюють для мене:

Опис проблеми

Проблема полягає у плагіні Maven Maven-surefire-плагін тільки у версіях 2.20.1 та 2.21.0. Я перевірив, і ви використовуєте версію 2.20.1.

Рішення 1

Оновіть версію плагіна до 2.22.0 . Додати в pom.xml :

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

Рішення 2

Зменшіть версію плагіна до 2,20 . Додати в pom.xml :

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

Рішення 3

Використовуйте тест конфігурації плагінаFailureIgnore . Додати в pom.xml :

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

Станом на сьогодні (30.10.2018 р.) Ми помітили, що наша конструкція ламається в Дженкінсі з цією помилкою.

Помилка трохи вводить в оману і потребує перегляду виходу дамп, target/surefire-reports/ щоб побачити таке повідомлення про помилку:

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

Це призвело мене до наступного повідомлення SO, в якому згадується можлива помилка у OpenJDK 181: Maven surefire не міг знайти клас ForkedBooter

Будь-який з виправлень у цій публікації вирішує мою проблему. Для конкретності я використав будь-яке з них:

1. Перехід від будівлі в контейнері докера maven:3.5.4-jdk-8доmaven:3.5.4-jdk-8-alpine
2. Перевірити навантажувач класу Spring Boot детально тут: https://stackoverflow.com/a/50661649/1228408

Ця частина FAQ про Surefire може допомогти вам:

Surefire виходить з ладу з повідомленням "Роздвоєний VM припиняється без належного прощання"

Surefire не підтримує тести або бібліотеки, що посилаються на System.exit (). Якщо вони це роблять, вони несумісні з перевіркою і, ймовірно, ви повинні подати проблему в бібліотеку / постачальника. Крім того, роздвоєний VM також може вийти з ладу з кількох причин, що також може спричинити цю проблему. Шукайте класичні файли "hs_err *", які вказують на збої VM, або вивчіть вихід журналу з запущеного Maven під час виконання тестів. Деякий "надзвичайний" вихід із збоїв у процесі може бути скинутий на консоль / журнал. Якщо це трапляється в середовищі CI і лише через деякий час працює, є велика ймовірність, що ваш тестовий набір витікає якийсь ресурс рівня ОС, що робить гірше для кожного запуску. Регулярні інструменти моніторингу рівня ос, можуть дати вам певну вказівку.

Просто зіткнувся з тією ж проблемою, java 8 на ubuntu

потім натрапив на https://stackoverflow.com/a/53016532/1676516

Здається, нещодавна помилка у версії плагінів-версії 2.22.1 з java 8 https://isissue.apache.org/jira/browse/SUREFIRE-1588

дотримуйтесь запропонованого рішення через локальні налаштування 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>

У мене був той самий випуск сьогодні, і для мене справжню проблему повідомляли далі в журналі з повідомленням Cannot use a threadCount parameter less than 1; 1 > 0 . При додаванні <threadCount>1</threadCount>в configfi-плагін-конфігурація інша помилка зникла.

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

... і так, я використовую і джуніт, і тестґан у цій тестовій структурі з міркувань відсталої сумісності.

Була подібна проблема під час виконання команди mvn із плагіном Jacoco на 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?

У JDK виникла помилка https://bugs.openjdk.java.net/browse/JDK-8081379

І рішенням було запустити mvn clean install з парам -XX: -UseLoopPredicate

Або просто зробіть оновлення JDK (я думаю, що новіша незначна версія працює)

Вимкніть useSystemClassLoader maven-surefile-плагін повинен допомогти

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

Якщо хтось включає в себе спеціальний аргумент argLine, ви повинні переглянути його, оскільки це, ймовірно, джерело ваших проблем із розподілом пам'яті.

Наприклад (я раніше):

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

Тепер я використовую жорсткі задані значення:

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

З будь-якої причини програми, які інтегруються з Surefire, такими як Jacoco, не вимагають достатньої кількості пам'яті для співіснування з тестуванням, яке відбувається під час збирання.

Я зіткнувся з цією проблемою також у контейнері Jenkins Docker (випробував jenkins: lts, ​​jenkins, jenkins: slim and jenkins: slim-lts. Я не хотів пройти всі сховища та оновити пом для кожного проекту, тому я щойно додав invalidClassPathURLCheck до виклику командного рядка Maven:

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

Використовуючи maven surefire 2.21.0, я вирішив проблему, змінивши reuseForksзначення параметра з true на false :

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.21.0</version>
            <configuration>
                <reuseForks>false</reuseForks>
            </configuration>
        </plugin>
    </plugins>
</build>

Весь мій розділ конфігурації під складання виглядав так:

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

Вам потрібно перевірити, чи ваша машина 64-бітна або 32-бітна. Якщо ваш апарат 32-розрядний, то аргумент пам’яті не повинен перевищувати 4096, навіть він повинен бути нижче 4 Гб. але якщо ваша машина 64-бітна, то встановіть Java 64-бітний і надайте JAVA_HOME у mvn.bat, який вказує на встановлення Java-64-біт.

Я стикався з випадком, коли жодна із наданих відповідей не вирішила питання. Це було із застарілим додатком, який, як правило, використовує log4j та SLF4J / logback.

Попередня ситуація: clean test збірки працювали нормально при запуску зсередини Eclipse, але при запуску в командному рядку ця помилка сталася. CI-розробка на CircleCI теж непогана.

Що я зробив: з чистого здогаду, чи правильно налаштувати logback-test.xml і набрати багатослівний запис журналу. Ось, я більше не відчував цієї помилки, і тепер я можу створити проект (як і модуль, в якому ця помилка сталася) з командного рядка.

Моя думка полягає в тому, що спосіб використання або налаштування фреймворків журналів може бути ще одним поясненням .

Чи справді це був конфлікт між log4j та logback? Або це просто те, що високий обсяг журналу, який випробовували тести, якимось чином переповнював буфер командного рядка? Не знаю. Для мене це залишається загадкою.

Я зіткнувся з подібною проблемою після оновлення до Java 12, для мене рішенням було оновлення версії jacoco <jacoco.version>0.8.3</jacoco.version>

у версії 2.22.2 виникають реальні проблеми з JVM-розщепленням. Використовуйте версію 2.20 - це працює як шарм!

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

Нещодавно я затримався з цією помилкою під час створення моїх контейнерних додатків з бамбуком:

org.apache.maven.surefire.booter.SurefireBooterForkException: роздвоєний VM припиняється без належного прощання

Після багатьох годин дослідження я це виправив. І я подумав, що було б корисно поділитися тут своїм рішенням.

Таким чином, помилки трапляються щоразу, коли mvn clean packageкоманда запуску бамбука для програм Java в докерних контейнерах. Я не експерт Maven, але проблема була в плагінах Surefire та Junit4, включених у весняний завантаження як залежність від Maven.

Щоб виправити це, вам потрібно замінити Junit4 на Junit5 і замінити плагін Surefire у вас pom.xml.

1. Виключення виключення вставки для пружинного завантаження:

<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. Додати нові залежності 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. Вставте новий плагін всередину розділу плагінів

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

Цього має бути достатньо для ремонту наростів з бамбука. Не забудьте також перетворити всі тести Junit4 для підтримки Junit5.

Налаштування цього в pom.xml працювало на мене. Але вам слід перевірити документацію для інших обхідних шляхів 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>

Роздвоєний JVM, використаний у тесті, не вистачає пам'яті. Рішенням може бути або відключення розгортання JVM та проведення тестів на головному JVM, гарантуючи, що у вас є достатня кількість пам'яті, або передача аргументів для збільшення пам'яті роздвоєного JVM

Перевірте рішення у цій відповіді

Я зіткнувся з цією проблемою під час побудови Дженкінса на машині Ubuntu.

/var/log/syslogповідомили Out of memory: Kill process 19557 (java) score 207 or sacrifice child.

Тому я дав машині Ubuntu більше місця для обміну . Відтоді проблеми вже немає.

Я вирішив цю проблему - закрити проклятий хромований браузер, який задушив пам'ять мого комп’ютера 🙄

Ви можете встановити параметри Java

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

У Windows (OpenJDK11, Maven 3.6.0, SUREFIRE 3.0.0-M1) я отримав цю першопричину:

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

і вирішується шляхом збільшення розміру файлу підкачки, наприклад, як це .

спробував усе вище, не вийшло. нижче рішення працює для мене:

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

У мене була та сама проблема і я вирішив використання Java 8 від Oracle замість Java 10 від Openjdk

Я спробував усі запропоновані рішення (форкінг, завантажувач системи, більше пам’яті тощо), нічого не вийшло.

Навколишнє середовище : збій не вдався в середовищі gitlab ci, запускаючи збірку всередині докерного контейнера.

Рішення : Ми використовували surefireplugin у версії 2.20.1 та оновлення до 2.21.0 або новішої версії (ми використовували 2.22.1) вирішили проблему.

Причина : SUREFIRE-1422 - surefire використовує команду ps, яка не була доступна в середовищі докера і призвела до "аварії". Ця проблема виправлена ​​в 2.21.0 або вище.

Завдяки цій відповіді з іншого питання: https://stackoverflow.com/a/50568662/2970422

Я також зіткнувся з цією проблемою на MacOS під час віддаленої налагодження тестового коду Selenium на порту 5005. Виявилася, що ця проблема була викликана залишком JVM, що залишився, що залишився. Вихід журналу до терміналу Eclipse IDE не показував основної проблеми, яка була вже використаною адресою . Повідомлення журналу було показане лише тоді, коли я запустив ту саму команду в терміналі MacOS, яку Eclipse насправді намагався запустити:

/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

Вбивство шахрайського екземпляра JVM (шукайте ім'я процесу Java в Моніторі діяльності) вирішило проблему. До речі, я запускаю плагін-версію версії 2.21.0 без проблем із відкритим jdk 8 (v1.8.0_212). Зверніть увагу, що всі шляхи будуть специфічними для вашого середовища збирання та, можливо, порту (адреса = 5005).

Я зіткнувся з тим же питанням, коли виконував одиничні тести, використовуючи тест Maven. Спробував змінити версійні версії, але це не працює. Нарешті вдалося вирішити наступним чином: EARLIER: (коли проблема виникала): javac є від jdk 1.8 java вказував на java bin від jdk 1.11 ТОЧНО: (коли питання вирішено): і javac & java вказують на бункери від jdk 1.8

З повагою Тея.

Я зазнав цієї помилки після того, як статична змінна члена в моєму тестовому класі називалася методом створення об'єкта (який використовувався в тестових випадках у всьому класі), і метод спричинив виняток.

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

Деякі виправлення включають в себе відтворення об'єкта всередині кожного тестового випадку та відповідно вилучення будь-яких винятків. Або ініціалізуючи об'єкт всередині методу @BeforeTest і переконавшись, що він правильно побудований.

У моєму випадку проблема стосувалася шляху робочої області, який мав бути дуже довгим. Тож я зробив рефакторинг шляху, і це вирішило для мене питання.