Discussion :

[pverley]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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

[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

[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

[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[]) ?)

[pverley]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.