Разветвленная виртуальная машина завершилась, не сказав прощания Сбой виртуальной машины или вызванный 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 и maven-failsafe-plugin - разветвленная виртуальная машина прервалась без должного прощания ) и нашла три решения, которые работают для меня:

Описание проблемы

Проблема с плагином maven maven-surefire-plugin только в версиях 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

Используйте конфигурацию плагина testFailureIgnore . Добавьте в pom.xml :

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

На сегодняшний день (30.10.2008) мы заметили, что наши сборки ломаются в Jenkins с этой ошибкой.

Эта ошибка немного вводит в заблуждение и требует просмотра выходных данных дампа, 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

Эта часть часто задаваемых вопросов Surefire может помочь вам:

Surefire завершается ошибкой с сообщением «Разветвленная виртуальная машина прервана без надлежащего прощания»

Surefire не поддерживает тесты или любые библиотеки, на которые ссылаются, вызывающие System.exit () в любое время. Если они это сделают, они несовместимы с верным, и вам, вероятно, следует сообщить о проблеме в библиотеку / поставщика. Кроме того, разветвленная виртуальная машина может также аварийно завершить работу по ряду причин, что также может привести к возникновению этой проблемы. Ищите классические файлы "hs_err *", указывающие на сбои виртуальной машины, или проверяйте вывод журнала при запуске maven при выполнении тестов. Некоторые «экстраординарные» выходные данные аварийных процессов могут быть сброшены в консоль / журнал. Если это происходит в среде CI и только после некоторого времени запуска, есть большая вероятность, что ваш набор тестов пропускает какой-то ресурс уровня ОС, который ухудшает ситуацию при каждом запуске. Регулярные инструменты мониторинга уровня ОС могут дать вам некоторое представление.

Просто столкнулся с той же проблемой, Java 8 на Ubuntu

потом наткнулся на https://stackoverflow.com/a/53016532/1676516

Кажется, недавняя ошибка в плагине surefire версии 2.22.1 с java 8 https://issues.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> в конфиг surefire-plugin другая ошибка исчезла.

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

... и да, я использую junit и testng в этой тестовой среде для обеспечения обратной совместимости.

Подобная проблема возникала при запуске команды 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 должно помочь

        <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 и jenkins: slim-lts. Я не хотел просматривать все репозитории и обновлять pom для каждого проекта, поэтому я просто добавил disableClassPathURLCheck к вызову командной строки 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>

Недавно я застрял с этой ошибкой при сборке контейнерных jar-приложений с помощью Bamboo:

org.apache.maven.surefire.booter.SurefireBooterForkException: разветвленная виртуальная машина прервана без правильного прощания

После многих часов исследований я исправил это. И я подумал, что было бы полезно поделиться своим решением здесь.

Так что ошибка возникает каждый раз, когда бамбук запускает mvn clean packageкоманду для java-приложений в док-контейнерах. Я не эксперт по Maven, но проблема была в плагинах Surefire и Junit4, включенных в spring-boot как зависимость от 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

Проверьте решение в этом ответе

Я столкнулся с этой проблемой во время сборки Jenkins на машине с Ubuntu.

/var/log/syslogсообщили Out of memory: Kill process 19557 (java) score 207 or sacrifice child.

Поэтому я дал машине Ubuntu больше пространства подкачки . С тех пор проблема ушла.

Мое решение этой проблемы было закрыть проклятый браузер Chrome, который душил память моего компьютера 🙄

Вы можете установить параметры 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, когда сборка выполнялась в контейнере Docker.

Решение : Мы использовали surefireplugin в версии 2.20.1, и обновление до 2.21.0 или выше (мы использовали 2.22.1) устранили проблему.

Причина : SUREFIRE-1422 - верный использует командуps , которая не была доступна в среде докера и привела к «краху». Эта проблема исправлена ​​в 2.21.0 или выше.

Благодаря этому ответу на другой вопрос: https://stackoverflow.com/a/50568662/2970422

Я также столкнулся с этой проблемой на MacOS во время удаленной отладки тестового кода Selenium через порт 5005. Оказалось, что проблема вызвана оставшейся верной JFM-версией, которая продолжала работать. Вывод журнала в терминал 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 в Activity Monitor) устранило проблему. Кстати, я использую плагин surefire версии 2.21.0 без проблем с открытым jdk 8 (v1.8.0_212). Обратите внимание, что все пути будут привязаны к вашей среде сборки и, возможно, к порту (адрес = 5005).

Я столкнулся с той же проблемой при запуске модульных тестов с использованием maven test. Попытка изменить верные версии, но это не работает. Наконец удалось решить следующим образом: РАННЕЕ: (когда возникла проблема): javac от jdk 1.8 java указывал на java bin из jdk 1.11 CURRENT: (когда проблема была решена): и 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 и обеспечения его правильной сборки.

В моем случае проблема была связана с рабочим пространством, которое было очень длинным. Так что я сделал рефакторинг пути, и это решило проблему для меня.