Разветвленная ВМ прекратилась, не сказав должным образом прощание. Сбой VM или System.exit

Ответ 1

У меня была такая же проблема, и я решил:

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

Ответ 2

В моем случае проблема связана с слишком длинным выводом журнала в консоль IntelliJ IDEA (окна ОС Windows 10).

Команда:

mvn clean install

Эта команда решила проблему для меня:

mvn clean install > log-file.log

Ответ 3

У меня очень похожая проблема (сборка 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>

Ответ 4

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

Эта ошибка немного вводит в заблуждение и требует просмотра вывода дампа в 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 подробно описано здесь: fooobar.com/questions/15797909/...

Ответ 5

Эта часть Surefire FAQ может помочь вам:

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

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

Ответ 6

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

потом наткнулся на fooobar.com/questions/16711061/...

Кажется, недавняя ошибка в плагине surefire версии 2.22.1 с java 8 https://issues.apache.org/jira/browse/SUREFIRE-1588

следовал предложенному ~/.m2/settings.xml пути через локальные настройки 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>

Ответ 7

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

Ответ 8

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

Ответ 9

Если кто-то включает настраиваемый аргумент argLine, вы должны пересмотреть, потому что это, скорее всего, источник ваших проблем с распределением памяти.

Пример (я имел обыкновение иметь):

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

Теперь я использую жесткие заданные значения:

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

По какой-либо причине приложения, которые интегрируются с Surefire, такие как Jacoco, не требуют достаточной памяти для сосуществования с тестированием, которое происходит во время сборки.

Ответ 10

Выключить 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>

Ответ 11

Я столкнулся с этой проблемой и в контейнере Jenkins Docker (попробовал jenkins: lts, jenkins, jenkins: slim and jenkins: slim-lts. Я не хотел проходить через все репозитории и обновлять pom для каждого проекта, поэтому я просто добавили disableClassPathURLCheck в вызов командной строки maven:

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

Ответ 12

Вам нужно проверить, является ли ваша машина 64-разрядной или 32-разрядной. Если ваш компьютер равен 32 бит, аргумент памяти не должен превышать 4096, даже он должен быть ниже 4 ГБ. но если ваш компьютер равен 64 бит, установите бит Java 64 и предоставите JAVA_HOME в mvn.bat, который указывает на установку 64-разрядной версии Java.

Ответ 13

Я недавно застрял в этой ошибке при создании контейнеров с контейнерами с помощью Bamboo:

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

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

Таким образом, ошибка происходит каждый раз, когда bamboo запускает mvn clean package для java-приложений в контейнерах докеров. Я не эксперт Maven, но проблема заключалась в плагинах Surefire и Junit4, включенных в весеннюю загрузку как зависимость от maven.

Чтобы исправить это, вам нужно заменить Junit4 на Junit5 и переопределить плагин Surefire в pom.xml.

Исключение вставки зависимостей весны от загрузки:

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

Ответ 14

Я встречал случай, когда ни один из ответов не дал этой проблемы. Это было с устаревшим приложением, которое, как оказалось, использует log4j и SLF4J/logback.

Предыдущая ситуация: clean test сборки работали нормально при запуске из Eclipse, но при запуске в командной строке эта ошибка произошла. CI строится на CircleCI, и он тоже отлично работает.

То, что я сделал: из чистой догадки, настраивает правильный logback-test.xml и набирает многословие ведения журнала. И вот, я больше не испытывал этой ошибки, и теперь я могу создать проект (а также модуль, в котором эта ошибка произошла) из командной строки.

Я хочу сказать, что способ использования или настройки фреймворков протоколирования может быть другим объяснением.

Это был конфликт между log4j и logback? Или это было просто из-за того, что большой объем журналов, созданных в результате тестов, как-то переполнил буфер командной строки? Я не знаю. Мне остается загадкой.

Ответ 15

Установка этого параметра в 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>

Ответ 16

Используя maven surefire 2.21.0, я решил проблему, изменив reuseForks параметра 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>

Ответ 17

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

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

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

Ответ 18

Мое решение этой проблемы состояло в том, чтобы закрыть проклятый хром-браузер, который задыхался от моей памяти компьютера 🙄

Ответ 19

Вы можете установить java-опции

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

Ответ 20

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

и решена за счет увеличения размера файла подкачки, например, как это.

Ответ 21

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

Ответ 22

В разветвленной JVM, использованной в тесте, не хватает памяти. Решением было бы либо отключить разветвление JVM и запустить тесты на основной JVM, чтобы убедиться, что у вас достаточно памяти, либо передать аргументы для увеличения памяти разветвленной JVM

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

Ответ 23

Я перепробовал все предоставленные решения (разветвление, загрузчик системы, больше памяти и т.д.), Ничего не получалось.

Среда: сборка завершилась неудачно в среде gitlab ci, когда сборка выполнялась в контейнере Docker.

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

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

Благодаря этому ответу на другой вопрос: fooobar.com/questions/1020176/...

Ответ 24

Я испытал эту ошибку после статической переменной-члена в моем тестовом классе, называемом методом создания объекта (который использовался в тестовых случаях по всему классу), и этот метод вызвал исключение.

// 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 и обеспечения его правильной сборки.

Ответ 25

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

Ответ 26

Когда я столкнулся с этой ошибкой, это связано с тем, что мой ulimit для открытых файлов (ulimit -n) был слишком низким. У него (как-то) было установлено только 256:

% ulimit -n
256

Ошибка исчезла после увеличения лимита:

% ulimit -n 3072
% ulimit -n     
3072

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

% ulimit -n 3073
ulimit: setrlimit failed: invalid argument

Или это может быть ниже вашего существующего предела, и вы можете столкнуться с другой основной причиной.

Ответ 27

В моем случае я забыл добавить зависимость в pom:

      <dependency>
          <groupId>org.aspectj</groupId>
          <artifactId>aspectjweaver</artifactId>
          <version>1.8.5</version>
      </dependency>

Просто убедитесь, что вы выбрали правильную версию (на сегодняшний день последняя версия 1.8.9)

Ответ 28

Я тоже испытал это, но в моем случае я написал собственный крючок для огурца

public class MappingFormatter implements gherkin.formatter.Formatter {

...

один из моих методов создавал исключение Null-указателя, из-за которого surefire выходил без регистрации ошибки.

Ответ 29

Недавно travis убил выполнение теста (не изменив ничего связанного (и удачного построения на машинах разработчика!)), таким образом СТРОИТЬ НЕИСПРАВНОСТЬ. Одной из причин было это (см. Ответ @agudian):

Surefire не поддерживает тесты или библиотеки, на которые ссылаются System.exit() `

(так как класс тестов действительно называется System.exit(-1)).

• Использование простого оператора return вместо этого помогает.

• Чтобы снова сделать Travis счастливым, мне также пришлось добавить параметры уверенного огня (<argLine>), предоставленные @xiaohuo. (также мне пришлось удалить -XX:MaxPermSize=256m, чтобы иметь возможность строить на одном из моих рабочих столов)

Выполнение только одной из двух вещей не сработало.

Подробнее читайте Когда нужно позвонить в System.exit в Java.

Ответ 30

Это также может произойти из-за совершенно другой проблемы. Например, в моем случае наша сборка Jenkins прерывалась с перерывами при выполнении тестов без каких-либо оснований.

Я просеял наши тесты, чтобы найти какое-либо событие System.exit(), но не было.

После еще большего копания я узнал, что это может произойти из-за ошибки JDK, которая могла вызвать эту регрессию.

JDK-6675699

Я все еще работаю над созданием этого исправления в наших сборках, вернусь и снова обновляю поток.