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

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

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

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

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

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

На сегодняшний день (30.10.2018) мы заметили, что наши сборки в 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

Отключите 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>

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

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

Похоже, это недавняя ошибка в плагине surefire версии 2.22.1 с 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 в этой тестовой среде по причинам обратной совместимости.

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

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

Например (раньше у меня было):

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

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

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

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

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

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

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

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

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

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

Я столкнулся с этой проблемой также в контейнере 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>

Похоже, это проблема синхронизации потоков на некоторых компьютерах с Windows. Если у вас возникла эта проблема с Windows, попробуйте перенаправить вывод в файл: mvn clean install > output.txt

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

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

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

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

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

У меня была такая же проблема с Java 8 и Spring boot 5.2.7 (плагин включен, из коробки). Версия плагина по умолчанию (2.22.2). В моем случае проблемы возникали только на некоторых машинах в команде, а на других машинах все было нормально. Я предполагаю, что это как-то связано с количеством обнаруженных maven ядер.

Я исправил это с помощью этих настроек:

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

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

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

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

Ознакомьтесь с решением в этом ответе

Недавно у меня была такая же проблема в приложении, созданном JHipster 6.10.5 с использованием spring -boot 2.2.7.RELEASE и плагина maven surefire 3.0.0-M4. Это было вызвано тайм-аутом из-за очень длинного журнала тестирования. Это было решено добавлением следующего параметра конфигурации в maven-surefire-plugin в pom.xml (в разделе pluginManagement):

‹ForkedProcessExitTimeoutInSeconds› 1200 ‹/forkedProcessExitTimeoutInSeconds›

См. https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkedProcessExitTimeoutInSeconds

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

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

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

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

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

Я обновил плагин surefire следующим образом, и это решило мою проблему:

           <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.22.2</version>
                <configuration>
                    <argLine>-Xmx1024m -XX:MaxPermSize=256m</argLine>
                    <forkCount>1</forkCount>
                    <reuseForks>true</reuseForks>
                    <runOrder>alphabetical</runOrder>
                </configuration>
            </plugin>

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

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

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

Я столкнулся с той же проблемой, что и я пытался скомпилировать проект maven, установленный на 1.7 в среде Windows 10 с JAVA = 1.8.

Я решил это, изменив версию java с 1.7 на 1.8, как показано ниже.

 <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.3</version>
    <configuration>
      <source>1.8</source>
      <target>1.8</target>
    </configuration>
  </plugin>

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

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

пробовал все выше, не сработало. ниже решение работает для меня:

<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

У меня была ситуация, похожая на Чада, но я нашел другой ответ.

Согласно документации плагина, вы не может использовать ${...} в <argLine>, потому что Maven подберет это для замены раньше, чем это сделает плагин surefire (или любой другой).

Начиная с версии 2.17, плагин поддерживает @{...} вместо ${...} для замены свойств.

Так, например, замените это

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

с этим

<argLine>XX:MaxPermSize=1024m @{moreArgs}</argLine>

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

С уважением, Тежа.

эту ошибку я смог удалить после добавления профиля:

<profile>
            <id>surefire-windows-fork-disable</id>
            <activation>
                <os>
                    <family>Windows</family>
                </os>
            </activation>
            <build>
                <pluginManagement>
                    <plugins>
                        <plugin>
                            <groupId>org.apache.maven.plugins</groupId>
                            <artifactId>maven-surefire-plugin</artifactId>
                            <configuration>
                                <forkCount>0</forkCount>
                                <useSystemClassLoader>false</useSystemClassLoader>
                            </configuration>
                        </plugin>
                    </plugins>
                </pluginManagement>
            </build>
        </profile>

Кажется, что это проблема Windows в отношении вилок maven surefire

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

// 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 и убедившись, что он построен правильно.

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

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

% ulimit -n
256

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

% ulimit -n 3072
% ulimit -n     
3072

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

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

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

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

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

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

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

public class MappingFormatter implements gherkin.formatter.Formatter {

...

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

Недавно трэвис прервал выполнение теста (не изменив ничего связанного (и успешных сборок на машинах разработчика!)), Таким образом, СБОЙ СБОРКИ. Одна из причин заключалась в следующем (см. Ответ @agudian):

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

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

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

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

Выполнение только одного из двух действий не помогло.

Для получения дополнительной информации прочтите Когда нам следует вызывать System.exit в Java.

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

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

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

JDK-6675699

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

Это может произойти из-за недостаточной памяти. Убедитесь, что у вас нет приложений, работающих в фоновом режиме во время работы mvn. В моем случае Firefox работал в фоновом режиме с большим использованием памяти.

Это определенно сработает .....

Добавьте следующие строки в файл POM и дайте сборку.

<plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-surefire-plugin</artifactId>
          <version>2.19.1</version>
          <configuration>
            <trimStackTrace>false</trimStackTrace>
            <includes>
              <include>**/*Test.class</include>
            </includes>
          </configuration>
        </plugin>

В моем случае это был мой код, вызывающий System.exit (0).

Вот выдержка из документации te:

Surefire не поддерживает тесты или какие-либо библиотеки, на которые есть ссылки, вызывающие System.exit () в любое время. Если они это сделают, они несовместимы с Surefire, и вам, вероятно, следует сообщить о проблеме в библиотеку / поставщику.

В моем случае помогло увеличение mem путем установки MAVEN_OPTS:

set MAVEN_OPTS=-Xmx1024m

Я использовал имя папки как test & demo, поэтому возникла эта проблема (виртуальная машина завершилась без должного прощания. Сбой виртуальной машины или вызов System.exit), но когда я дал имя папки как test_demo затем он решил эту проблему. (эта проблема возникает в ОС Windows с символом "&".)