Bonjour,
Je pose ici un problème complexe sur lequel nous sommes deux à travailler
depuis deux semaines (pas à plein temps je vous rassure). En désespoir de
cause, je poste ma question ici en français et en anglais sur les newsgroup
d'IBM
Ce problème concerne Java (IBM/WebSphere), et la Debian Woody (stable) avec
tous les derniers patchs de sécurité (kernel 2.4.18-1 patch 13). Une expertise
en C est la bienvenue pour comprendre le problème.
Je préviens que ce mail est long.
WebSphere 5.0.1 a été installé sur mon serveur Debian (plus d'intérêt à
utiliser Debian que la version de RedHat supporté par IBM) avec succès:
1 journée de travail pour <<guider>> l'installeur vers un script rpm maison
en juin. Depuis lors tout fonctionnait bien - nous faisons tourner des tests
automatiques tous les soirs à partir de nos sources sur CVS...
Depuis deux semaines, rien ne va plus - et je me souviens avoir fait un
apt-get upgrade à cet époque. Le symptome: la JVM d'IBM crash de façon
plus ou moins aléatoire, et quasi systématiquement dans certains cas.
Pour mettre en évidence le problème, java -version suffit !!
yma ~> /opt/WebSphere5/AppServer/java/bin/java -version
stackpointer=0xbfff9a78
JVMXM004: JVM is performing abort shutdown sequence
JVMDG217: Dump Handler is Processing a Signal - Please Wait.
JVMDG221: Dump Handler Caught Internal Exception 2 Processing JAVADUMP for
Signal 11.
JVMDG215: Dump Handler has Processed Exception Signal 11.
Segmentation fault
Le système de fichiers n'est pas corrompu. La même installation WebSphere
recopiée (et reconfigurée) sur une Mandrake 9.1 fonctionne parfaitement.
Nous avons généré les logs avec strace sur cette commande, dont voici
l'extrait juste avant le SEGV:
mprotect(0x41435000, 61440, PROT_READ|PROT_WRITE) = 0
mprotect(0x41435000, 61440, PROT_READ|PROT_EXEC) = 0
stat64("/opt/WebSphere5/AppServer/java/jre/lib/rt.jar", {st_mode=S_IFREG|0755, s
t_size=8835141, ...}) = 0
gettimeofday({1069664829, 654322}, NULL) = 0
lstat64("/opt", {st_mode=S_IFLNK|0777, st_size=14, ...}) = 0
readlink("/opt", "/usr/local/opt", 4096) = 14
--- SIGSEGV (Segmentation fault) ---
Suspicion sur le lien symbolique, mais un autre run:
brk(0x8079000) = 0x8079000
stat64("/home/users/tester/tmp/java/jre/classes", 0xbfffeac0) = -1 ENOENT (No su
ch file or directory)
brk(0x807c000) = 0x807c000
brk(0x8085000) = 0x8085000
--- SIGSEGV (Segmentation fault) ---
La JVM crash un peu plus loin comparé au run précédent.
Conclusion: un problème de pointeur dans le vide !
Hypothèse: bug de malloc dans la glibc 2.2.5 de Debian qui ne ferait pas
le brk correctement (Mandrake livre la version 2.3.1)
Problème: pourquoi cela a fonctionné pendant plus de 4 mois ? Et ne fonctionne
plus maintenant ?
Est-il possible de connaître les versions de libc que le système a installé
et mis-à-jour sur Debian ? afin de retourner sur l'éventuelle ancienne version
qui fonctionnait correctement.
J'envisage sinon d'ajouter la glic 2.3.1 sur la Debian (dans /usr/local/lib
depuis les sources). Est-ce que cette solution pourrait fonctionner ?
Merci d'avance pour toute piste, et n'hésitez pas à me réclamer plus
d'informations en privé si nécessaire...
--
Yves Martin
