La VM biforcata è terminata senza salutare correttamente. Chiamata crash della VM o System.exit

Aiutatemi a risolvere questo problema. Non capisco esattamente cosa significhi l'errore nel registro.

[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

Ho avuto lo stesso problema e risolto aggiungendo:

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

L'intero elemento del plugin è:

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

Nel mio caso, il problema era correlato all'output del log troppo lungo nella console IDEA di IntelliJ (sistema operativo Windows 10).

Comando:

mvn clean install

Questo comando mi ha risolto il problema:

mvn clean install > log-file.log

Ho un problema molto simile ( build di Maven e plug-in maven-fail-safe - La VM biforcata è terminata senza salutare correttamente ) e ho trovato tre soluzioni che funzionano per me:

Descrizione del problema

Il problema è con il plugin maven maven -surefire-plugin solo nelle versioni 2.20.1 e 2.21.0. Ho controllato e usi la versione 2.20.1.

Soluzione 1

Aggiorna la versione del plug-in alla 2.22.0 . Aggiungi in pom.xml :

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>2.22.0</version>
</plugin>

Soluzione 2

Esegui il downgrade della versione del plug-in alla 2.20 . Aggiungi in pom.xml :

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>2.20</version>
</plugin>

Soluzione 3

Usa il test di configurazione del pluginFailureIgnore . Aggiungi in pom.xml :

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

Ad oggi (30/10/2018), abbiamo notato che le nostre build si rompevano a Jenkins con questo errore.

L'errore è un po 'fuorviante e richiesto guardando l'output del dump target/surefire-reports/ per vedere il seguente messaggio di errore:

Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter

Questo mi ha portato al seguente post SO che menziona un possibile bug in OpenJDK 181: Maven surefire non è riuscito a trovare la classe ForkedBooter

Entrambe le correzioni in quel post risolvono il mio problema. Per essere precisi, ho usato uno di questi:

1. Passaggio da un edificio nel contenitore finestra mobile maven:3.5.4-jdk-8amaven:3.5.4-jdk-8-alpine
2. Sostituzione del caricatore di classi di Spring Boot dettagliato qui: https://stackoverflow.com/a/50661649/1228408

Questa parte delle Domande frequenti su Surefire potrebbe aiutarti:

Surefire fallisce con il messaggio "La VM biforcuta è terminata senza salutare correttamente"

Surefire non supporta test o librerie referenziate che chiamano System.exit () in qualsiasi momento. In tal caso, sono incompatibili con surefire e probabilmente dovresti presentare un problema con la libreria / fornitore. In alternativa, la VM con fork potrebbe anche arrestarsi in modo anomalo per una serie di motivi, che possono anche causare questo problema. Cerca i classici file "hs_err *" che indicano gli arresti anomali della macchina virtuale o esamina l'output del registro dall'esecuzione di maven quando vengono eseguiti i test. Alcuni output "straordinari" da processi di arresto anomalo potrebbero essere scaricati nella console / nel registro. Se ciò accade in un ambiente CI e solo dopo un certo periodo di tempo, c'è una buona probabilità che la tua suite di test stia perdendo una sorta di risorsa a livello di sistema operativo che peggiora le cose ad ogni esecuzione. I normali strumenti di monitoraggio a livello di sistema operativo potrebbero darti qualche indicazione.

Stava affrontando lo stesso problema, Java 8 su Ubuntu

poi mi sono imbattuto https://stackoverflow.com/a/53016532/1676516

Sembra un bug recente nel plugin surefire versione 2.22.1 con java 8 https://issues.apache.org/jira/browse/SUREFIRE-1588

seguito la soluzione suggerita tramite le impostazioni mvn locali ~/.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>

Ho avuto lo stesso problema oggi e per me il vero problema è stato riportato più in alto nel registro con un messaggio Cannot use a threadCount parameter less than 1; 1 > 0 . Quando si aggiunge <threadCount>1</threadCount>la configurazione del plugin surefire, l'altro errore è scomparso.

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

... e sì, sto usando sia junit che testng in questo framework di test per motivi di compatibilità con le versioni precedenti.

Si è verificato un problema simile durante l'esecuzione del comando mvn con il plug-in Jacoco su 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?

Si è verificato un errore in JDK https://bugs.openjdk.java.net/browse/JDK-8081379

E la soluzione era eseguire mvn clean install con param -XX: -UseLoopPredicate

O semplicemente fare un aggiornamento a JDK (penso che la versione minore più recente funzioni)

Disattiva useSystemClassLoader di maven-surefile-plugin dovrebbe aiutare

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.22.0</version>
            <configuration>
                <useSystemClassLoader>false</useSystemClassLoader>
            </configuration>
        </plugin>

Se qualcuno include un argomento argLine personalizzato, è necessario riconsiderare perché è probabilmente la fonte dei problemi con l'allocazione della memoria.

Per esempio (prima avevo):

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

Ora uso valori specificati con difficoltà:

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

Per qualsiasi motivo, le applicazioni che si integrano con Surefire come Jacoco, non richiedono memoria sufficiente per coesistere con i test che si verificano al momento della creazione.

Ho riscontrato questo problema anche in un contenitore Jenkins Docker (provato jenkins: lts, ​​jenkins, jenkins: slim e jenkins: slim-lts. Non volevo esaminare tutti i repository e aggiornare il pom per ogni progetto, quindi ho ho appena aggiunto disableClassPathURLCheck alla chiamata da riga di comando di maven:

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

Usando maven surefire 2.21.0 ho risolto il problema cambiando il reuseForksvalore dell'opzione da vero a falso :

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

Tutta la mia sezione di configurazione sotto build sembrava:

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

È necessario verificare se la macchina è a 64 bit o 32 bit. Se la macchina è a 32 bit, l'argomento della memoria non deve superare 4096, anche se deve essere inferiore a 4 GB. ma se la tua macchina è a 64 bit, installa Java 64 bit e fornisci JAVA_HOME in mvn.bat che punta all'installazione java a 64 bit.

Ho incontrato un caso in cui nessuna delle risposte fornite ha risolto il problema. Era con un'applicazione legacy che utilizza log4j e SLF4J / logback.

La situazione precedente: le clean testbuild funzionavano bene quando venivano avviate da Eclipse, ma quando venivano avviate dalla riga di comando, si verificava questo errore. Anche le build CI su CircleCI sono andate bene.

Quello che ho fatto: per pura ipotesi, è configurare un vero e proprio logback-test.xml e comporre la verbosità della registrazione. Ecco, non ho più riscontrato questo errore e ora posso costruire il progetto (così come il modulo in cui si è verificato questo errore) dalla riga di comando.

Il mio punto è che il modo in cui vengono utilizzati o configurati i framework di registrazione potrebbe essere un'altra spiegazione .

È stato davvero un conflitto tra log4j e logback? O era solo che l'alto volume di registrazione prodotto dai test traboccava in qualche modo un buffer della riga di comando? Non lo so. Rimane un mistero per me.

Ho riscontrato un problema simile dopo l'aggiornamento a Java 12, per me la soluzione era aggiornare la versione Jacoco <jacoco.version>0.8.3</jacoco.version>

la versione 2.22.2 presenta problemi reali con le JVM biforcute. Usa la versione 2.20 - funziona come un incantesimo!

<groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
<version>2.20</version>

Di recente mi sono bloccato con questo errore durante la creazione delle mie applicazioni jar containerizzate con Bamboo:

org.apache.maven.surefire.booter.SurefireBooterForkException: la VM con fork è terminata senza salutare correttamente

Dopo molte ore di ricerche l'ho risolto. E ho pensato che sarebbe stato utile condividere la mia soluzione qui.

Quindi l'errore si verifica ogni volta che bamboo esegue il mvn clean packagecomando per le applicazioni java nei contenitori della finestra mobile. Non sono un esperto di Maven, ma il problema riguardava i plug-in Surefire e Junit4 inclusi in Spring-Boot come dipendenza Maven.

Per risolverlo devi sostituire Junit4 per Junit5 e sovrascrivere il plugin Surefire in te pom.xml.

1. Esclusione dell'inserzione della dipendenza dallo stivale interno:

<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. Aggiungi nuove dipendenze 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. Inserisci un nuovo plugin nella sezione dei plugin

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

Questo dovrebbe essere sufficiente per riparare le costruzioni di bambù. Non dimenticare inoltre di trasformare tutti i test Junit4 per supportare Junit5.

L'impostazione di questo in pom.xml ha funzionato per me. Ma dovresti controllare la documentazione per altre soluzioni alternative 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>

La JVM biforcuta utilizzata nel test sta esaurendo la memoria. La soluzione sarebbe disabilitare il fork di una JVM ed eseguire i test sulla JVM principale assicurando di avere memoria sufficiente o passare argomenti per aumentare la memoria della JVM biforcuta

Scopri la soluzione in questa risposta

Ho riscontrato questo problema durante le build di Jenkins su una macchina Ubuntu.

/var/log/syslogsegnalato Out of memory: Kill process 19557 (java) score 207 or sacrifice child.

Ho quindi dato alla macchina Ubuntu più spazio di scambio . Da allora, il problema è sparito.

La mia risoluzione a questo problema è stata quella di chiudere il dannato browser Chrome che stava soffocando la memoria del mio computer 🙄

È possibile impostare le opzioni Java

SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate

mvn clean install

Su Windows (OpenJDK11, Maven 3.6.0, SUREFIRE 3.0.0-M1) ho avuto quella causa principale:

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

e risolto aumentando le dimensioni del file di paging, ad esempio in questo modo .

provato tutto sopra, non ha funzionato. la soluzione seguente funziona per me:

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

Ho avuto lo stesso problema e risolto utilizzando Java 8 di Oracle anziché Java 10 di Openjdk

Ho provato tutte le soluzioni fornite (fork, systemloader, più memoria ecc.), Niente ha funzionato.

Ambiente : build non riuscita nell'ambiente gitlab ci, esecuzione della build all'interno di un contenitore docker.

Soluzione : abbiamo utilizzato surefireplugin nella versione 2.20.1 e l'aggiornamento a 2.21.0 o versioni successive (abbiamo utilizzato 2.22.1) risolto il problema.

Causa : SUREFIRE-1422 - surefire utilizza il comandops , che non era disponibile nell'ambiente docker e ha provocato il "crash". Questo problema è stato risolto in 2.21.0 o versioni successive.

Grazie a questa risposta da un'altra domanda: https://stackoverflow.com/a/50568662/2970422

Mi sono imbattuto in questo problema anche su MacOS durante il debug remoto del codice di test Selenium sulla porta 5005. Il problema si è rivelato essere causato da una JVM rimanente funzionante. L'output del registro sul terminale IDE di Eclipse non mostrava il problema sottostante che era l' indirizzo già in uso . Il messaggio di registro è stato mostrato solo quando ho eseguito lo stesso comando in un terminale MacOS che Eclipse stava effettivamente cercando di eseguire:

/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

Uccidere l'istanza JVM canaglia (cercare un nome di processo java in Activity Monitor) risolto il problema. A proposito, sto eseguendo il plug-in surefire versione 2.21.0 senza problemi con open jdk 8 (v1.8.0_212). Si noti che tutti i percorsi saranno specifici per l'ambiente di compilazione e possibilmente per la porta (indirizzo = 5005).

Stavo affrontando lo stesso problema quando eseguivo i test unitari usando il test Maven. Ho provato a cambiare le versioni infallibili ma non ha funzionato. Finalmente sono riuscito a risolvere come segue: PRECEDENTE: (quando si stava verificando il problema): javac è di jdk 1.8 java puntava al java bin di jdk 1.11 CORRENTE: (quando il problema è stato risolto): sia javac che java stanno puntando al bidoni da jdk 1.8

Saluti Teja.

Ho riscontrato questo errore dopo che una variabile membro statica nella mia classe di test ha chiamato un metodo per creare un oggetto (che è stato utilizzato nei casi di test in tutta la classe) e il metodo ha causato un'eccezione.

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

Alcune correzioni includono la ricostruzione dell'oggetto all'interno di ciascun caso di test e la cattura di eventuali eccezioni di conseguenza. O inizializzando l'oggetto all'interno di un metodo @BeforeTest e assicurando che sia stato creato correttamente.

Nel mio caso, il problema era legato al percorso dell'area di lavoro che era troppo lungo. Quindi ho fatto un refactoring di percorso e questo mi ha risolto il problema.