"Java fourchue VM sortie anormale "erreur des tests junit
J'ai un test Java Junit qui passe lorsqu'il est exécuté seul sur une machine de développement. Nous avons également un travail hudson qui exécute tous les tests, appelés via ant, sur un nœud Mac OS X 10.4 avec Java 1.5. Le test passait jusqu'à récemment dans la version hudson, mais maintenant (sans modification de code connexe), un test échoue à chaque fois avec l'erreur suivante:
Message d'erreur
Forked Java VM s'est arrêté anormalement . S'il vous plaît noter l'heure dans le rapport ne reflète pas le temps jusqu'à la VM sortie.
Trace de la pile
junit.framework.AssertionFailedError: Forked Java VM s'est arrêté anormalement . S'il vous plaît noter l'heure dans le rapport ne reflète pas le temps jusqu'à la VM sortie.
googler montre que beaucoup d'autres semblent avoir rencontré le même problème, mais je n'y ai pas trouvé de réponse.
J'ai fait face à un problème similaire. J'ai exécuté les tests Junit comme une tâche de fourmi. J'ai ajouté la propriété showoutput = "yes" ant junit et ai exécuté la tâche ant junit. Il a ensuite montré la trace de la pile des exceptions qui a provoqué la fermeture de jvm forké.
Pour moi, c'était une "Java.lang.OutOfMemoryError" dans le forked VM (tâche junit avec fork = "yes") qui a fait apparaître ce message dans le VM principal.
Le OutOfMemory était visible dans le journal de la fourmi (enfin, il est visible puisqu'il est toujours présent).
J'utilise Ant 1.7.1, donc pas d'espoir avec la mise à niveau de ant.
Après avoir placé les mêmes paramètres VM dans "Exécuter> Outils externes> Outils externes> JRE" que dans Eclipse.ini (-Xms40m -Xmx512m -XX: MaxPermSize = 256M), le problème est résolu.
Je garde la fourchette à "non" pour être sûr d'utiliser les paramètres.
Cela peut se produire lorsqu'une exception RuntimeException non capturée est levée. Malheureusement, la tâche junit ant ne génère pas l'exception. Il n'est donc pas facile de déterminer la cause. Vous pouvez contourner ce problème en exécutant le scénario de test à partir de la ligne de commande où l'exception sera affichée.
Java <vm-args> org.junit.runner.JUnitCore <test-class-name>
Dans mon cas, une exception IllegalArgumentException était émise.
Je crois avoir vu cette erreur une fois lorsque je me suis retrouvé avec plusieurs versions de junit sur mon classpath. Peut-être la peine de vérifier.
Le VM se bloque-t-il? Pouvez-vous trouver un fichier de vidage (appelé hs_err_pid*.log)? Si tel est le cas, le fichier de vidage vous donnera des indices sur la raison pour laquelle cela se produit.
J'ai eu ce problème et il s'avère que le processus appelait en fait System.exit (). Cependant, il y avait aussi un bug dans Ant où cela apparaissait parfois. Je pense que Ant 1.7.1 a corrigé le bogue. Assurez-vous donc que vous utilisez cette version.
J'ai plusieurs bocaux Junit dans mon classpath. l'un est de fourmi et l'autre est de WAS. Comme j'ai enlevé que l'erreur est partie ... Version Ant que j'utilise 1.8
J'ai eu exactement la même chose il y a quelque temps. Le problème est que System.exit () est appelé quelque part. Il peut être difficile à trouver, car l'appel peut provenir de votre code ou de l'une des bibliothèques que vous utilisez.
J'ai fait face au même problème. Le problème était avec la génération de code d'octet avec se moquer de la classe de configuration; Nous avons changé l'importation en
import static org.junit.Assert.assertNotNull;
import static org.mockito.Mockito.times;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;
et cela a fonctionné.
J'ai rencontré le problème après avoir réinstallé une nouvelle version de NetBeans sur un disque dur externe, mis à niveau Junit en même temps et utilisé mon ancien espace de travail.
Pour moi, la solution au même problème était simple:
Ajoutez simplement la bibliothèque JUnit au projet properties => Libraries => Compile Tests et Run Tests.
Donc, dans mon cas, il s’agissait simplement d’une bibliothèque manquante ou d’un conflit de version de JUnit.
Dans mon cas, il s'agit d'une exception non interceptée dans un initialiseur/méthode/bloc statique dans une classe.
Plus précisément, une classe appelant une méthode statique dans une autre classe déclenchait une exception NumberFormatException.
L'ajout de "showoutput = true" à la tâche dans build.xml n'a pas aidé à résoudre le problème. Le bloc statique étant l’une des premières choses à exécuter, la JVM a explosé avant de pouvoir produire quoi que ce soit.
Pour nous, c’est en fait que nous avons utilisé accidentellement Ant 1.7.x à la place de notre ancienne version ant qui était compatible avec notre environnement Weblogic 8.1/JDK 1.4.x. Nous avons résolu ce problème en rétablissant Ant Home dans Eclipse-> Windows-> Préférences-> Ant-> Runtime sur notre ancienne version de Ant.
Cordialement Klas
J'ai résolu mon problème en définissant la variable d'environnement suivante:
Variable: _Java_OPTIONS Valeur: -Xms128m -Xmx512m
Dans mon cas, le chemin de classe sur lequel mes tests étaient exécutés dépassait la longueur maximale autorisée par le système d'exploitation pour une variable d'environnement (alias problème du chemin de classe Linux trop long).
La solution consistait à créer un jar de cheminement . Étapes simplifiées:
Utilisez jar (ou votre IDE) pour créer un jar de votre projet, nous l'appellerons MyProject.jar
Faire un fichier appelé Manifest.txt avec le texte
Chemin de la classe: MyProject.jar
- Exécutez la ligne de commande jar cette
jar cfm PathingJar.jar manifest.txt MyRootPackage/*. class
Ensuite, dans votre outil de génération, exécutez votre directive test sur le fichier JAR de cheminement (ne mélangez pas d'autres classes ou fichiers JAR). Ensuite, j'ai pu exécuter mes tests sans cette exception.