Java VM: reproductible SIGSEGV sur 1.6.0_17 et 1.6.0_18, comment signaler?

MODIFIER: Cette reproductible SIGSEGV qui se passe sur une machine Linux avec plus d'un proc et de plus de 2 go de mem, si Java est par défaut -mode serveur. Curieusement, si je force "client" il n'y a pas de crash plus... (je ne suis pas encore trop sûr de quoi faire avec mon reproductible SIGSEGV, mais il est intéressant par ailleurs).

D'abord noter que c'est un peu connexe, mais non identique à celui-ci parce que, dans notre cas, c'est seulement un SIGSEGV qui se passe, et nous pouvons de manière fiable la déclencher:

JVM OutOfMemory erreur "spirale de la mort" (pas de fuite de mémoire)

C'est lié, car il arrive quand nous nourrir de notre application avec un "déluge de données": les données sont à venir à partir de fichiers texte et le nombre croqué (oui, financière de nombreux calculs en Java).

Je peut sûrement déclencher une JVM à SIGSEGV en utilisant uniquement valable code Java.

NOTE: je peux invariablement crash à la fois de la JVM 1.6.0_17 adn JVM 1.6.0_18 et cette question n'est pas sur la façon de contourner ce problème (par exemple en jouant avec les paramètres de la VM peut résoudre le problème, mais je ne suis pas après ce, je veux savoir quoi faire avec ce toujours-des SIGSEGV).

J'ai une solution de contournement qui consiste tout simplement à l'aide de Java 1.5 lors du lancement de notre application mobile (bien que toujours à l'aide de la version 1.6 de Java pour exécuter IntelliJ IDEA, etc. sur la même machine, en même temps), mais ma question est de savoir si cela doit être signalé ou non et, si elle doit, de la façon de le signaler, sachant que le journal lui-même contient des informations confidentielles (le hs_err_..._log).

Erreur matérielle peut être exclu pour:

ce qui se passe sur une station de travail qui atteint régulièrement mois de disponibilité (je ne le redémarrer lorsque les correctifs de sécurité critiques touchant mon abaissé et durci Debian Linux sont émises, qui n'arrive pas souvent) et sur les applications qui ne plantent jamais (ce qui rend très peu probable que ce soit un problème matériel sur la machine [ci-dessous])
même application fonctionne parfaitement sur la même machine sous une JVM 1.5, en vertu de la charge (c'est la façon dont je suis le test de l'application: j'ai simplement le lancer sous un 1.5 VM)
même application fonctionne parfaitement bien sur plus d'une centaines de clients de la machine sous le même (gigantesque) de la charge (jamais écrasé une fois sur Windows + JVM 1.5 ou 1.6 et jamais écrasé une fois sur OS X + JVM 1.5 ou 1.6 [un crash signifierait un instant de l'appel téléphonique du client])
autre application sur la même machine et le même 1.6.0_17 ou 1.6.0_18 JVM ne plantent jamais (par exemple, j'ai deux instances de IntelliJ IDEA fonctionnant comme deux utilisateurs différents sur la même machine et ils ne tombent pas en panne)
machine est testée avec memtest "régulièrement" (avant d'installer un nouvel OS, dont la dernière qui s'est passé lorsque j'ai installé Debian Lenny, n'y a pas longtemps)

Voici la reproductible sur demande SIGSEGV:

... $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)

Le lancement de l'application, de lui donner un "déluge de données", attendez quelques secondes...

Puis, 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.donc+0x4bc080]' est la même pour les 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.donc+0x4d88f0]" est la même pour les 1.6.0_18 à chaque SIGSEGV)

Le problème est que le fichier journal contient des informations confidentielles
qui ne peut être partagée.

La reproduction d'une "petite affaire" que reproduire le problème n'est pas réaliste: il est semblable à la question ci-dessus, cela n'arrive que lorsqu'un "déluge de données" est alimenté à l'application.

Noter 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'ai eu Debian Etch précédemment) n'a PAS de déclenchement qui SIGSEGV une fois.

Mais cela ne signifie pas que la JVM n'est pas en faute: il pourrait toujours avoir une JVM question.

Dois-je le signaler cela et comment? (en gardant à l'esprit que l'écriture d'un "reproductible minuscule cas de test" est illusoire et que le journal contient des informations confidentielles qui ne doivent pas être divulgués). Dois-je simplement éditer le journal et l'envoyer?

Quelle est la procédure pour signaler de tels reproductible SIGSEGV lors de votre journal contient des informations exclusives et lorsqu'un cas de test reproduisant la question n'est pas de façon réaliste, faisable?

Avez-vous le succès de l'ouverture d'un tel bug et puis le voir résolu dans une prochaine Java version?

Pensez-vous que c'est une bonne chose "pour la communauté Java" pour signaler une telle question, ou je ne devraient tout simplement pas la peine parce que ce n'est pas important?

source d'informationauteur SyntaxT3rr0r

6

J'ai eu le même problème de la mise à niveau de JDK 1.6_18 et il semble résolu en utilisant l'une des 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 ne l'ai toujours pas vérifier, (c'est un environnement de production), mais je pense que l'erreur est due à deux raisons:

1) Mauvais réglage tas et/ou Permanente de l'espace (je pense JDK 1.6 besoin de plus d'espace dans le tas et stable que les précédentes versions de la JVM), 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 de la JVM n'a pas été en mesure d'écrire l'heapdump et nous avons obtenu SIGSEGV seulement (les versions précédentes a écrit des tas de vidage dans le répertoire de travail).

Vérifier -server -XX:+UseParallelGC -XX:-UseGCOverheadLimit options de trop. Je pense que jouer avec les paramètres de la VM n'est pas une solution de contournement, mais la bonne approche aussi parce que le garbage collector (et pas seulement) entre 1.5 et 1.6.
5

Le problème est que le fichier journal
contient des informations confidentielles
ne peut pas être partagée. La reproduction d'une "minuscule
cas de test" permettant de reproduire le problème
n'est pas réaliste soit

Si vous ne pouvez pas fournir de Soleil avec une reproductibilité de cas de test, ils ne regardent même pas. Les chances sont bonnes qu'ils seront les ignorer, même si vous ne vous fournir un produit de cas de test. Le bug processus de soumission au Soleil laisse beaucoup à désirer.

Dois-je le signaler cela et comment?

Si vous ne pouvez pas venir avec une reproductibilité de cas de test, ne vous embêtez pas. S'ils ne peuvent pas reproduire le problème, qu'attendez-vous de faire?

Noter que la même application,
sur exactement le même matériel, avec
exactement la même JVM, mais un autre
la version de Linux (j'ai eu Debian Etch
précédemment) n'a PAS de déclencheur
SIGSEGV une fois.

Fonctionne-t-il une autre boîte avec le même matériel et la même version de Linux?
1

Si cela peut aider, la soumission de bug lien dans votre rapport de crash a cet avertissement:

En outre, Sun Microsystems respecte votre désir de la vie privée. Les données personnelles collectées à partir de ce programme ne sera pas vendu, donné ou partagé avec des organisations externes au Soleil. Nous utiliserons ces données pour les communications avec vous afin de clarifier les questions concernant le rapport que vous avez soumis et/ou état de ce rapport. Les questions que vous rapport peut être rendu disponible à d'autres JDC Membres ou les clients de Sun, cependant, vos données personnelles seront gardées confidentielles. Si vous n'êtes pas à l'aise avec les conditions ci-dessus, s'il vous plaît ne pas appuyer sur le bouton envoyer. Si vous avez des questions, veuillez vous référer à notre Politique De Confidentialité.

Personnellement, je voudrais signaler si il était possible de remettre le segment de code en question avec les journaux, si les données ne sont pas trop sensibles (peut-être les données peuvent être masqué ou dissimulé dans les journaux?).

Il est impossible pour vous de vraiment juger si le bug est "important" ou pas pour les autres, à moins que vous ne peut savoir ce qu'est réellement la cause. Les rapports, il pourrait être la première étape dans le Soleil, les ingénieurs de trouver la cause de quelque chose de sérieux.
0

La première question à vous poser est:
- Suis-je utiliser officiellement prise en charge de la distribution Linux?
Si non, passer à une qui est.

Si vous êtes, alors signalez-le au Soleil!

Vous devez vous connecter pour publier un commentaire.