Discussion :

[tich29]

Bonjour tout le monde,

Voilà mon problème : je travaille sur une application de cartographie en temps réelle basée sur WorldWind (et donc JOGL) en ce qui concerne l'affichage. Après quelques heures d'exécution, j'ai un crash de la JVM. Une première analyse de plusieurs fichiers de log hs_err_pidXXX.log montrent que les crashs apparaissent systématiquement sur des appels à méthodes natives (JNI) mais pas tout le temps sur les mêmes fonctions : soit des appels à OpenGL soit des appels à OpenSplice (implémentation du standard DDS) qui permet de distribuer des données à l'ensemble d'un système.
En fonction de la machine sur laquelle l'application est exécutée, la JVM met plus ou moins de temps à planter :
1) Sur ma machine, l'application à tourner 8h avant de planter mais il y a peu de données à transiter sur DDS. D'un autre côté, j'ai fait un test où j'ai désactivé la représentation opengl de données mises à jour via OpenSplice et après un nuit d'exécution (~12 h d'exécution) il n'y avait pas de plantage.
2) Sur une autre machine où tournent plusieurs autres applications qui publient des données sur le bus DDS et un serveur mysql, j'ai pu observé un crash de l'application au bout de 2h.
3) Sur une plateforme constituée de 2 machines et un server, l'application plante régulièrement toutes les 4h.
Après avoir relu plusieurs fois le code OpenGL de mon application, je ne vois rien qui puisse entraîner une fuite mémoire (pas d'utilisation de call list donc, peu d'objets affichés dans les scénario de tests, ... bref on est très loin de ce qu'on peut voir dans les jeux vidéos) mais d'après ma rmarque en 1) en désactivant l'affichage des objets je n'ai pas eu de plantage après 12h d'exécution.

Je n'ai pas encore analysé toutes les données que j'ai (notamment les fichier core) mais étant donné que le plantage n'apparaît pas tout le temps dans les mêmes fonctions natives et que le temps avant le plantage à l'air de dépendre de la charge allouée sur la machine (nombre d'application, quantité de données qui transitent ...), je me dirige vers un problème de mémoire (allocation, fuite, ...) dans les lib JNI. Peut-être que je tire des conclusions trop vite ? Peut-être quelqu'un a déjà été confronté à ce genre de problème ?

Une dée que j'ai en tête, c'est de supprimer tous les appels à la lib OpenSplice pour les remplacer avec des bouchons (purement Java) mais j'ai des délai très très short donc je me demande si ne serait pas plus rapide d'identifier la cause du problème pour pouvoir la corriger.

Bref, étant donné que pour l'instant je n'ai aucune piste sérieuse, j'aimerais savoir s'il il existe un moyen de connaître l'état de la mémoire au moment du crash d'une JVM et en particulier la mémoire consommée par chaque lib JNI si c'est possible et donc de me permettre d'identifier un éventuelle fuite mémoire.

Si quelqu'un a des pistes, des conseils, ... ce sera sympa.
Merci d'avance.

[tchize_]

si crash de la JVM il y a, il y a effectivement des très très fortes chances que les librairies JNI aient un problème. Même si votre application était trop gourmande au delà des limite, jamais, dans une implémentation correcte coté jni, cela ne doit entrainer un crash de la JVM. La libraire JNI doit remonter correctement une exception, la plus explicite possible.

Bref, crash jvm = bug = rapport auprès de la librairie en question. Reste à identifier laquelle des deux est coupable. Est-il envisageable de faire tourner un test n'utilisant qu'une des deux librairies?

[tich29]

Yep, j'ai lancé hier un test hier où les appels à la lib OpenSplice sont très limités (seulement quelques un au démarrage de l'application). Du coup j'ai toujours l'affichage de certains objets (pour lesquels le plantage apparaît) qui est mis à jour fréquemment (toutes les secondes ou toutes les 100 ms je ne me rapelle plus) à partir de la données lu sur le premier appel à OpenSplice. L'application tourne depuis 16h donc très probable que le problème viennent de OpenSplice.
D'après les logs c'est un débordement mémoire donc je pencherais pour une fuite mémoire quelque part dans la lib OpenSplice ou une des surcouches qu'on utilise.
J'ai discuté avec quelques autres personnes et on m'a proposé d'instrumenter l'appli avec valgrind.

[tchize_]

un bon outil. Il y a aussi electric fence pour les problèmes liées à malloc/free