Java VM: SIGSEGV reproductible sur 1.6.0 17 et 1.6.0 18, comment signaler?
EDIT : Ce SIGSEGV reproductible se produit sur une machine Linux avec plus d'un proc et plus de 2 Go de mem, donc Java est par défaut en mode-server. Fait intéressant, si je force "- client", il n'y a plus de crash... (Je ne sais toujours pas trop quoi faire de mon SIGSEGV reproductible mais c'est quand même intéressant).
Notez d'abord que ceci est un peu lié mais pas identique à ce qui suit car dans notre cas, c'est seulement un SIGSEGV qui se produit, et nous pouvons de manière fiable déclenchez-le:
Erreur JVM OutOfMemory "spirale de la mort" (pas de fuite de mémoire)
C'est lié car cela se produit lorsque nous alimentons notre application avec un "déluge de données": les données proviennent de fichiers texte puis de chiffres croqués (oui, le nombre financier en Java).
Je peux déclencher de manière fiable une JVM vers SIGSEGV en utilisant uniquement du code Java valide.
NOTE: Je peux invariablement planter les deux JVM 1.6.0_17 adn JVM 1.6.0_18 et cette question ne porte pas sur la façon de contourner ce problème problème (par exemple, jouer avec les paramètres de la machine virtuelle peut résoudre le problème mais je ne suis pas après cela, je veux savoir quoi faire avec ce SIGSEGV toujours reproductible).
J'ai une solution de contournement qui consiste simplement à utiliser Java 1.5 lors du lancement de notre application (tout en utilisant Java 1.6 pour exécuter IntelliJ IDEA, etc. sur la même machine, simultanément), mais ma question est de savoir si cela doit être signalé ou non et, s'il le faut, comment le signaler en sachant que le journal lui-même contient des informations propriétaires informations (le hs_err_ complet..._journal).
Une erreur matérielle peut être exclue pour:
Cela se produit sur un poste de travail qui atteint régulièrement des mois de disponibilité (je ne le redémarre que lorsque des correctifs de sécurité critiques affectant mon Debian Linux réduit et durci sont émis, ce qui n'arrive vraiment pas souvent) et sur lesquels les applications ne plantent jamais (ce qui rend très improbable qu'il s'agisse d'un problème matériel])
-
Même application fonctionne parfaitement sur cette même machine sous une JVM 1.5 sous la même charge (c'est ainsi que je teste l'application: je la lance simplement sous une machine virtuelle 1.5)
La même application fonctionne parfaitement bien sur plus d'une centaine de clients sous la même charge (gigantesque) (ne s'est jamais écrasé une fois sur Windows + JVM 1.5 ou 1.6 et ne s'est jamais écrasé une fois sur OS X + JVM 1.5 ou 1.6 [un crash signifierait un appel téléphonique instantané du client])
-
Autre application sur cette même machine et la même JVM 1.6.0_17 ou 1.6.0_18 ne plante jamais (par exemple, j'ai deux instances d'IntelliJ IDEA fonctionnant en tant que deux utilisateurs différents sur cette même machine et elles ne plantent pas)
-
La machine est testée avec memtest "régulièrement" (avant d'installer un nouveau système d'exploitation, ce qui s'est produit pour la dernière fois lorsque j'ai installé Debian Lenny, il n'y a pas si longtemps)
Voici le SIGSEGV reproductible à la demande:
... $uname -a
Linux saturn 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 GNU/Linux
... $ export /home/wizard/jdk1.6.0_17/bin:$PATH
... $ java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
Lancez l'application, nourrissez-la d'un "déluge de données", attendez quelques deuxième...
Alors, invariablement, pour 1.6.0_17:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb76d0080, pid=30793, tid=2514328464
#
# JRE version: 6.0_17-b04
# Java VM: Java HotSpot(TM) Server VM (14.3-b01 mixed mode linux-x86 )
# Problematic frame:
# V [libjvm.so+0x4bc080]
#
# An error report file with more information is saved as:
# /home/wizard/hs_err_pid30793.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
(notez que la ligne '[libjvm.so+0x4bc080] ' est cohérent pour 1.6.0_17 à chaque SIGSEGV)
Ou pour 1.6.0_18:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb77468f0, pid=722, tid=2514516880
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) Server VM (16.0-b13 mixed mode linux-x86 )
# Problematic frame:
# V [libjvm.so+0x4d88f0]
#
# An error report file with more information is saved as:
# /home/wizard/hs_err_pid722.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted
(notez que la ligne "[libjvm.so+0x4d88f0] " est cohérent pour 1.6.0_18 à chaque SIGSEGV)
Le problème est que le fichier journal contient des informations confidentielles qui ne peut être partagée.
Reproduire un" minuscule cas de test " qui reproduit le problème n'est pas réaliste non plus: c'est similaire au problème lié ci-dessus, cela ne se produit que lorsqu'un "déluge de données" est envoyé à l'application.
Notez que la même application, sur exactement le même matériel, avec exactement la même JVM mais une autre version de Linux (j'avais Debian Etch auparavant) n'a PAS déclenché ce SIGSEGV une seule fois.
Mais cela ne signifie pas que la JVM n'est pas en faute: cela pourrait toujours être un problème de JVM.
Dois-je signaler cela et comment? (en gardant à l'esprit que l'écriture d'un "cas de test minuscule reproductible" est délirante et que le journal contient des informations propriétaires qui ne devraient pas être divulguées). Dois-je simplement modifier le journal et l'envoyer?
Quelle est la procédure pour signaler un tel SIGSEGV reproductible lorsque votre journal contient des informations propriétaires et lorsqu'un scénario de test reproduisant le problème n'est pas réalisable?
L'un d'entre vous a-t-il réussi à ouvrir un tel bogue et à le voir ensuite résolu dans une version Java ultérieure?
Pensez-vous qu'il est bon "pour la communauté Java" de signaler un tel problème ou je ne devrais pas m'embêter parce que ce n'est pas important?
4 answers
J'ai eu un problème similaire de mise à niveau vers JDK 1.6_18 et il semble résolu en utilisant les options suivantes:
-server
-Xms256m
-Xmx748m
-XX:MaxPermSize=128m
-verbose:gc
-XX:+PrintGCTimeStamps
-Xloggc:/tmp/gc.log
-XX:+PrintHeapAtGC
-XX:+PrintGCDetails
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath="/tmp"
-XX:+UseParallelGC
-XX:-UseGCOverheadLimit
# Following options just to remote monitoring with jconsole, useful to see JVM behaviour at runtime
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=12345
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=MyHost
Je n'ai toujours pas vérifié (c'est un environnement de production), mais je pense que l'erreur était due à deux raisons:
1) Un mauvais réglage sur le tas et / ou l'espace permanent (je pense que JDK 1.6 a besoin de plus d'espace dans le tas et permanent que les versions JVM précédentes) a provoqué une OutOfMemoryError, mais
2) dans le mauvais réglage d'origine quelqu'un a écrit
-XX:+HeapDumpOnOutOfMemoryError="/tmp"
Et pas
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath="/tmp"
Donc probablement JVM n'a pas été en mesure d'écrire le heapdump et nous avons obtenu SIGSEGV uniquement (les versions précédentes ont écrit heap dump dans le répertoire de travail).
Vérifiez les options -server -XX:+UseParallelGC -XX:-UseGCOverheadLimit aussi. Je pense que jouer avec les paramètres de la machine virtuelle n'est pas une solution de contournement, mais la bonne approche aussi parce que garbage collector (et pas seulement) a changé entre 1.5 et 1.6.
Le problème est que le fichier journal contient des informations confidentielles ne peut pas être partagée. Reproduire un " minuscule cas de test " qui reproduisent le problème ce n'est pas réaliste non plus
Si vous ne pouvez pas fournir à Sun un cas de test reproductible, ils ne le regarderont même pas. Il y a de bonnes chances qu'ils l'ignorent même si vous fournissez un cas de test utilisable. Le processus de soumission de bogues chez Sun laisse beaucoup à désirer.
Dois-je signaler ceci et comment?
Si vous ne pouvez pas trouver un cas de test reproductible, ne vous embêtez pas. S'ils ne peuvent pas reproduire le problème, qu'attendez-vous de faire?
Notez que la même application, sur exactement le même matériel, avec exactement la même JVM mais une autre version de Linux (j'avais Debian Etch précédemment) n'a PAS de déclencheur SIGSEGV une fois.
Fonctionne-t-il sur une boîte différente avec le même matériel et la même version de Linux?
Si cela aide, le lien de soumission de bogue dans votre rapport de crash a cette clause de non-responsabilité:
De plus, Sun Microsystems respecte votre désir de confidentialité. Les données personnelles collectées dans le cadre de ce programme ne seront pas vendues, données ou partagées avec des organisations externes à Sun. Nous utiliserons ces données pour communiquer avec vous afin de clarifier les problèmes concernant le rapport que vous avez soumis et/ou l'état de ce rapport. Les problèmes que vous signalez peuvent être mis à la disposition d'autres membres du JDC ou de Sun clients, cependant vos données personnelles seront gardées confidentielles. Si vous n'êtes pas à l'aise avec les conditions ci-dessus, veuillez ne pas appuyer sur le bouton Soumettre. Si vous avez des questions, veuillez vous référer à notre Politique de Confidentialité.
Personnellement, je le signalerais s'il était possible de remettre le segment de code en question avec des journaux, si les données ne sont pas trop sensibles (peut-être que les données peuvent être masquées ou obscurcies dans les journaux?).
Il est impossible pour vous de vraiment juger si le bug est "important" ou pas pour les autres, sauf si vous pouvez savoir ce qui le cause réellement. Signaler cela pourrait être la première étape pour que les ingénieurs de Sun découvrent la cause de quelque chose de grave.
La toute première question que vous devriez vous poser est:
- Est-ce que j'utilise une distribution Linux officiellement prise en charge?
Sinon, passez à celui qui est.
Si c'est le cas, signalez-le au Soleil!