Crash JVM sur cluster

Version imprimable

1 pièce(s) jointe(s)

Bonjour,

Pour exécuter un algorithme génétique, je lance sur un cluster des milliers d'occurence d'un même jar, chacun avec un jeu de paramètre de configuration qui dépend des résultats de la génération précédente. Pour caricaturer on a :
Code:

1 2 java -jar programme.java fichier_config_###.xml
lancé des milliers de fois sur 256 nodes différents.

Chaque fois que je soumets un job sur le cluster, il y a toujours une des simulations qui pète. Mais l'erreur intervient à des moments différents et sur des nodes du cluster différents...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fcd8f87c751, pid=11670, tid=140519607047952 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode linux-amd64) # Problematic frame: # V [libjvm.so+0x1d5751] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. #
J'ai mis un fichier d'erreur complet en pièce jointe.
Je ne connais pas ce genre de message d'erreur. Apparament c'est la JVM qui crashe.

Est-ce que qqn pourrait me dire svp comment il faut interpréter un tel message d'erreur et comment s'y prendre pour trouver la source du problème ?

D'avance merci,
Philippe.

10/06/2011, 11h28
Jimmy_

Bonjour,

Oui la jvm crashe sur du code natif, donc autant dire que cela risque d'être un peu compliqué pour trouver l'erreur.

Dans un premier temps je pense qu'il faut upgrader votre JVM et trouver la dernière version disponible.

Car : vm_info: Java HotSpot(TM) 64-Bit Server VM (10.0-b22) for linux-amd64 JRE (1.6.0_06-b02), built on Mar 25 2008 01:03:02 by "java_re" with gcc 3.2.2 (SuSE Linux)

Ca fait plus de deux ans, beaucoup de bug on certainement été corrigé depuis ce temps.
10/06/2011, 11h33
pverley

Merci Jimmy pour ta réponse rapide.

En effet nous devrions voir si une mise à jour de la JVM solutionne le problème. Je vais me rapprocher des administrateurs du cluster pour voir avec eux si un update est possible.

Ce que je ne mesure pas : est-ce que c'est notre code (disons le tout court, pas de grande qualité pour la gestion de la mémoire) qui peut amener à ce genre d'erreur ? Ou c'est une erreur qui au final peut être relativement indépendante du programme exécutée par la JVM ?

Philippe
10/06/2011, 11h53
tchize_

Non, en aucun cas du code "pur java" ne peux amener ce genre d'erreur. Un crash d'un JVM est toujours une situation inadmissible pour la JVM. Votre code peux faire des pieds et des mains, le pire que vous pourriez avoir c'est des tartines de Throwable.

C'est un peu comme si un code C qui gère mal sa mémoire faisait disjoncter le batiment :) Ce n'est pas normal et la machine (virtuelle dans le cas de java) est le coupable ;)

Si, je dit bien si, un code java génèrerais ce genre de crash, alors ce serait toujours au même endroit à priori.

Concrètement, ce que je suggérerais:

1) upgrader la JVM vers la dernière version (pour éliminer tout bug déjà identifié et corrigé par sun)
2) essayer de virer /appli/intel/* du LD_LIBRARY_PATH avant de lancer (histoire d'être sur que c'est pas lui qui injecterais des cacas dans la mémoire de la jvm) pour rester sur une config "standard" (/lib;/usr/lib).

PS: j'espère que le code java ne fait pas appel à la classe com.sun.unsafe.UnSafe :)
10/06/2011, 14h04
Logan Mauzaize

J'ai déjà eu un crash de JVM avec un NullPointerException dans un actionPerformed ... Merci AWT ;)
Tout appel à du code natif peut produire cet effet.
Quasiment tout programme faisant un minimum de chose finit par appeler du code natif étant donné que ce sont les librairies natives qui assurent le "run everywhere" de Java.

Etrange ce "CompilerThread" ... C'est le thread qui fait la transformation bytecode -> code natif ?
Tu fais rien de spécial dans la méthode Simulation.saveNbYieldperTime(F[J)V
(Simulation.saveNbYieldperTime(float, boolean[]) ?)

Merci Nemek d'avoir attiré mon attention sur la ligne
Code:

1 2 C2:214 ! Simulation.saveNbYieldperTime(F[J)V (207 bytes)
J'ai repassé les logs des différents crash et voilà ce que j'obtiens :

C2:214 ! Simulation.saveNbYieldperTime(F[J)V (207 bytes)
C2:211 ! Simulation.saveBIOM_migrants_perTime(F[D)V (222 bytes)
C2:210 ! Simulation.saveABD_migrants_perTime(F[J)V (277 bytes)
C2:216 ! Simulation.saveMeanTLperTime(F[F[D)V (252 bytes)
C2:217 ! Simulation.saveMeanTLCatchperTime(F[F[F)V (251 bytes)
C2: 68 Cohort.fishing2(F)V (1469 bytes)

Toutes ces méthodes en Simulation.save### sont conçues de la même manière :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 public void saveNbYieldperTime(float time, long[] nY) { File targetPath, targetFile; PrintWriter pr; String nbYieldFile = outputFileNameTab[numSerie] + "_yieldNB_Simu" + numSimu + ".csv"; targetPath = new File(outputPathName + outputFileNameTab[numSerie]); targetPath.mkdirs(); try { targetFile = new File(targetPath, nbYieldFile); nbYieldTime = new FileOutputStream(targetFile, true); } catch (IOException ie) { System.err.println(ie.getMessage()); return; } pr = new PrintWriter(nbYieldTime, true); pr.print(time); for (int i = 0; i < species.length; i++) { pr.print(";"); pr.print(nY[i]); } pr.println(); pr.close(); }
Je vais donc creuser du côté de PrintWriter, je ne sais pas ce qu'il y a derrière, si c'est du natif ou pas...
Là où je continue de douter c'est qu'une des simulations à péter sur la méthode Cohort.fishing2 qui ne fait que des calculs arithmétiques.

Encore merci, j'ai déjà bien avancé grâce à vos réponses.
Philippe.

encore une fois le pétage est du à la jvm, le fait qu'elle crashe, etc un bug *de la jvm*.

Avez vous tenté l'upgrade?

Aussi, pour rappel (même si ce n'est absolument pas lié) TOUJOURS fermer ses stream!

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
       try {
            targetFile = new File(targetPath, nbYieldFile);
            nbYieldTime = new FileOutputStream(targetFile, true);
            try{
                pr = new PrintWriter(nbYieldTime, true);
                try{
                    pr.print(time);
                    for (int i = 0; i < species.length; i++) {
                        pr.print(";");
                        pr.print(nY[i]);
                    }
                    pr.println();
                } finally {
                    pr.close();
                }
            } finally {
                nbYieldTime.close();
            }
        } catch (IOException ie) {
            System.err.println(ie.getMessage());
            return;
        }

10/06/2011, 17h35
pverley

Merci Tchize !

Le message est bien passé, on peut toujours essayer de se demander quelle partie du code amène la JVM a péter, il n'en reste pas moins que c'est un bug de la JVM.
Je vais voir pour mettre à jour la JVM (les admins du cluster ne sont pas très java friendly...) ça me parait en effet l'étape incontournable à ce stade.

Oui, toujours fermer les streams... je reprends tout juste ce code et il y a encore bcp de travail pour tout cleaner. Merci pour la piqure de rappel ;-)

Je ferme pour l'heure ce fil, considérant qu'il n'est pas la peine de s'interroger plus longuement tant qu'on aura pas mis à jour la JVM.
Philippe.
10/06/2011, 19h32
tchize_
pour info, je connais pas ton cluster, mais si les admins sont chiant, sous linux, java ne demande pas d'installation -> tu prend l'archive, tu la décompresse, et tu te fais une structure genre
Code:

1 2 3 4 5 6 dossier/ monAppli/ unTruc.jar java/ Toute la jvm ici lancer.sh = java/bin/java -jar monAppli/unTruc.jar
T'empaquette le tout dans un zip et tu dit aux admins "c'est ça mon appli à mettre sur le cluster" :p
30/06/2011, 15h10
pverley

Pour clore ce fil : j'ai procédé comme suggéré par tchize en décompressant la dernière JVM sur mon espace disque et ensuite j'exécute mon script en utilisant la JVM à jour (6u26) au lieu de celle du cluster et c'est tout bon ==> plus de plantage :ccool:

Merci encore à vous.
Philippe.
30/06/2011, 15h36
Jimmy_

Plus de 2 ans la jvm ... soit une éternité en java, si ça n'avais pas été ça tu étais très mal ... :mrgreen:

Bravo.