Проблемы с плагином SureFire: - "Разломанная виртуальная машина завершена, не говоря о том, чтобы прощаться. Сбой VM или System.exit?"

При запуске единичных тестов происходит следующее исключение:

org.apache.maven.lifecycle.LifecycleExecutionException: ExecutionException; nested exception is java.util.concurrent.ExecutionException: java.lang.RuntimeException: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Любые предложения?

Ответы

Ответ 1

Любые предложения?

Сообщение об ошибке исключения, вероятно, объясняет, что происходит. Один из ваших модульных тестов имеет

  • называется System.exit(), или
  • сломал жгут unit test или
  • сделал что-то, что разбило JVM, в котором он работал.

Мы не можем сказать вам, что это было.

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

В файле журнала может быть больше информации о нарушении unit test. Проверьте, что/them.

Ответ 2

Я столкнулся с той же проблемой при запуске "пакета" maven. Проблема была решена, когда я выполнил цель "очистить" перед выполнением "пакета"

Ответ 3

У меня была такая же проблема. Оказалось, что я обновил свои библиотеки без обновления моей версии java, и у меня было слишком много нового servlet.jar. Я нашел следующее сообщение в журналах до "разветвленного исключения bla bla":

Caused by: java.lang.UnsupportedClassVersionError: javax/servlet/ServletRequest : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.getMethod0(Class.java:2670)
at java.lang.Class.getMethod(Class.java:1603)
at org.apache.maven.surefire.util.ReflectionUtils.tryGetMethod(ReflectionUtils.java:57)
at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.isSuiteOnly(JUnit3TestChecker.java:64)
at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.isValidJUnit3Test(JUnit3TestChecker.java:59)
at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.accept(JUnit3TestChecker.java:54)
at org.apache.maven.surefire.common.junit4.JUnit4TestChecker.accept(JUnit4TestChecker.java:51)
at org.apache.maven.surefire.util.DefaultScanResult.applyFilter(DefaultScanResult.java:97)
at org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:194)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:92)

Помогло обновление JVM.

Ответ 4

У меня была такая же проблема ТОЛЬКО у дженкинсов, как сообщалось в принятом ответе, и потерял один час, чтобы понять, что проблема в том, что у задания имени дженкинса было место в нем, это что-то делало (все еще не знаю, что ) в вызове плагина surefire сходят с ума, поскольку имя задания - это папка внутри рабочего пространства jenkins, где все есть.

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

Надеюсь, это поможет кому-то другому. Это было подтверждено 2.14.1 и 2.16.

Ответ 5

Это может иметь отношение к правам администратора. Я столкнулся с такой же проблемой при запуске сборки mvn clean install от Cygwin.

Теперь каждый раз для сборки я запускаю cygwin как "Запуск от имени администратора", и проблема решена.