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

192

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

[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
astack
источник
7
Пожалуйста, перезапустите Maven с -e и -X, как показано в выводе, и вставьте то, что он вам дает. Кроме того, вы создаете свой собственный код или существующую библиотеку? Если вы создаете свой собственный код, вызываете ли вы System.exit (int) где-нибудь? Если вы создаете существующую библиотеку, где вы взяли исходный код?
Dylon
@Dylon Edwards: Это существующий исходный код, проект OpenDayLight для реализации SDN.
Astack
Недавний сценарий, который воспроизводил проблему, был при запуске тестовых наборов из файлов XML. Если XML-файл определяет класс, который больше не существует, или ссылается на старое полностью определенное имя класса, был перемещен, то JVM не сможет загрузить класс. Это приводит к странному сообщению, которое вы заметили. Если присмотреться к любой трассировке стека, это поможет вам определить такие проблемы, в этом случае нет необходимости передавать ключи -e или -X.
Ивайло Славов
@astack, что оказалось решением для этого? не могли бы вы отметить ответ или написать свой, пожалуйста.
Наман

Ответы:

122

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

<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>
xiaohuo
источник
7
+1 Я использовал этот фрагмент, дословно, и это исправило мою проблему с Travis-CI. Мы не получили это ни на одной из рабочих станций наших разработчиков.
StartupGuy
7
Выше не решил проблему для меня. Эта проблема может возникать, когда одна из зависимостей (jar и т. Д.) В .m2повреждена. Удалите ~ / .m2 / репозиторий rm -rf ~/.m2/repositoryи затем mvn installразрешите его для меня.
ch4nd4n
2
Скопируйте и вставьте это в мой файл pom, и это сработало как очарование, спасибо
Flaom
8
Предупреждение о 64-битном сервере OpenJDK VM: игнорирование опции MaxPermSize = 256 м; поддержка была удалена в 8.0
Julien
2
Может ли кто-нибудь объяснить, что он на самом деле делает и как это влияет?
Боргматер
72

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

Команда:

mvn clean install

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

mvn clean install > log-file.log
Михаил
источник
Слишком длинные журналы были проблемой и для меня! Перенаправление в лог-файл не помогло. Изменение некоторых наиболее распространенных операторов ведения журнала, от информации до отладки, решило проблему
RvPr
7
Слишком много журналирования было реальной проблемой в моем случае!
Чо
1
Не забывайте и про поток ошибок: mvn clean test 2> err.txt 1> out.txt или mvn clean test> out.txt 2> & 1 или mvn clean test 2> & 1 | tee out.txt Во время перенаправления вы можете смотреть вывод в другой консоли с меньшим + F out.txt
radzimir
1
Для меня переход с windows cmd на консоль Intellij решил это.
Брокколи
3
Действительно, перенаправление в файл журнала решает эту проблему.
horizon7
41

У меня очень похожая проблема ( сборка 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>
Михал Орлинский
источник
Для меня эта комбинация работала благодаря: <plugin> <groupId> org.apache.maven.plugins </ groupId> <artifactId> maven-surefire-plugin </ artifactId> <версия> 2.22.1 </ version> <конфигурация> < testFailureIgnore> true </ testFailureIgnore> </ configuration> </ plugin>
Абхишек,
Спасибо за это, используя maven:3.6.0-jdk-10Docker изображение и обновление до версии 3.0.0-M3с maven-surefire-pluginрешено для меня.
Даниалк
21
Относительно решения 3: можем ли мы действительно сказать, что игнорирование неудачных испытаний - это решение? Какой смысл иметь тесты, если их результат не имеет смысла?
Ulukai
Я только что обновил maven-surefire-plugin до 2.22.2 и работает отлично!
Кшиштоф Вальчевский,
Ага! Обновление до v2.22.2 верного решения решило это и для меня. Спасибо!
Миг
32

На сегодняшний день (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
majikman
источник
1
Спасибо. В нашем случае помог переход с 1.8.0_161-b12 на 11.0.1 + 13.
Karussell
1
Это именно та проблема, с которой я столкнулся на моем Дженкинсе, и теперь она решена. Спасибо.
Вигнеш Пай
У ОП было еще одно сообщение об ошибке:The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
PetroCliff
1
@PetroCliff Я признал, что это была ошибка, которую я также получил, когда сказал, что «мы заметили, что наши сборки ломаются в Дженкинсе с этой ошибкой ». Затем я продолжил объяснять, что ошибка вводит в заблуждение и что фактическая ошибка была в surefire-reports.
Мажикман
25

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

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

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

agudian
источник
9

Просто столкнулся с той же проблемой, 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>
Махмуд Саид
источник
1
Простое добавление более свежей версии 3.0.0-M1 (например) решило проблему.
Галигатор
6

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

javabeangrinder
источник
6

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

andreyro
источник
6

Отключить 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>
Лои Цао
источник
1
Это тот, который исправил это для меня. Я строил maven через артефакт на образе докера, поставленном в очередь из gitlab. Было трудно заставить работать репрезентативную настройку, и после того, как было опробовано много опций для точных настроек, этот исправил ее с версией 2.22.0.
Ричард Баун
1
Я должен добавить эту опцию для каждой работы Maven в Gitlab CI и понятия не имею, почему.
cljk
5

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

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

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

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

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

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

Чад Ван Де Хей
источник
5

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

mvn test -DargLine="-Djdk.net.URLClassPath.disableClassPathURLCheck=true"
Кевин Дюбуа
источник
5

Используя 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>
Чаки Иштван
источник
4

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

Нареш Сингх
источник
4

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

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

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

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

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

AbVog
источник
Проголосование, потому что это действительно может решить / избежать / обойти проблему. Я использую slf4j и sl4j-simple в Windows, и вялый вывод тоже указал мне в этом направлении. Настройка System.setProperty (SimpleLogger.DEFAULT_LOG_LEVEL_KEY, "warn"); сделал свое дело. Понижение maven-surefire-plugin до 2.18.1 тоже сработало.
Marcus
4

Я столкнулся с подобной проблемой после обновления до java 12, для меня решение было обновить версию jacoco <jacoco.version>0.8.3</jacoco.version>

Макс Воронцов
источник
Это была действительно проблема, с которой я столкнулся в своем проекте. Жаль, что этот ответ не так заметен ...
OmriYaHoo
4

версия 2.22.2 имеет реальные проблемы с разветвленными JVM. Используйте версию 2.20 - она ​​работает как шарм!


<groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
<version>2.20</version>
Alex
источник
Хм, это действительно помогает!
Чжэнь Чжан
Да, v2.22.2есть проблема с maven:3.6-jdk-8-alpine. Так раздражает!
КимчиМан
3

Недавно я застрял с этой ошибкой при сборке контейнерных 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.

ripreal
источник
2

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

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

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

Muji
источник
1

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

Ананд Рокзз
источник
1

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

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

Abhimanyu
источник
1

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

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

Радослав Иванов
источник
В Linux (4.4.0-145-generic, amd64) изменено с Oracle JRE 8 на AdoptOpenJDK_8u202b08 для задания Jenkins, и оно начало выдавать ошибку «fork»: - «Выполнение проверки по умолчанию цели org.apache.maven.plugins» : maven-surefire-plugin: 2.19.1: тест не пройден: разорванная виртуальная машина завершилась без должного прощания. Произошел сбой виртуальной машины или вызван System.exit? " - Вернулся к Oracle JRE и ошибка прекратилась. Это единственная работа (наша примерно из 300), чтобы иметь эту проблему. К счастью, это только внутренний проект, а не поставляемый клиентом, мы можем хранить его в Sun / Oracle JRE.
Роберт
1

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

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

Юэбинг Цао
источник
Эта точная версия плагина помогла мне. Кстати, моя конфигурация: 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"
tworogue
1

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

Франческо Борзи
источник
1

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

Окружающая среда : сборка завершилась неудачно в среде 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

джокер
источник
1

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

Грегг Лейхтман
источник
1

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

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

Тея
источник
0

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

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

user2812481
источник
0

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

Тьяго-разви
источник
Это было на машине с Windows?
hithwen
Да, он работает в Windows.
Тиаго-Девел
Как ты это нашел?
dzieciou