Java VM: reproduzierbare SIGSEGV auf beiden 1.6.0_17 und 1.6.0_18, wie zu berichten?

BEARBEITEN: Diese reproduzierbare SIGSEGV geschieht auf einem Linux-Rechner mit mehr als einem proc und mehr als 2GB mem, also Java ist standardmäßig auf den -server-Modus. Interessanterweise genug, wenn ich Gewalt "-client" es gibt keinen Absturz mehr... (ich bin noch nicht sicher, was zu tun mit meinem reproduzierbare SIGSEGV aber es ist trotzdem interessant).

Ersten Hinweis, dass dies ein bisschen verwandt, aber nicht identisch mit dem folgenden, denn in unserem Fall ist es nur ein SIGSEGV das passiert, ist zuverlässig und wir können es auslösen:

JVM OutOfMemory-Fehler "Todesspirale" (nicht memory-leak)

Ist es ähnlich, da es passiert, wenn wir füttern Sie unsere app mit einer "Flut von Daten": Daten aus text-Dateien und dann die Zahl-gecrashtes (ja -, Finanz-Zahl Knirschen in Java).

Kann ich zuverlässig auslösen, eine JVM zu SIGSEGV nur mit Gültiger Java-code.

HINWEIS: ich kann immer ein Absturz die beiden JVM 1.6.0_17 adn JVM 1.6.0_18 und diese Frage ist nicht etwa, wie man dieses Problem lösen (zum Beispiel das spielen mit dem VM Parameter kann das Problem zu beheben aber ich bin mir nicht danach, ich will wissen, was mit diesem zu tun immer reproduzierbar SIGSEGV).

Ich habe eine Problemumgehung, die Sie einfach besteht in der Verwendung von Java 1.5 bei der Markteinführung unserer app (während immer noch mit Java 1.6 ausführen, IntelliJ IDEA, etc.. auf der gleichen Maschine gleichzeitig), aber meine Frage ist, ob dies gemeldet werden sollte oder nicht und, wenn es sein sollte, so melden Sie es wissen, dass das Protokoll selbst enthält urheberrechtlich geschützte Informationen (die vollständige hs_err_..._log).

Hardware-Fehler ausgeschlossen werden können:

dies passiert auf einer workstation, die regelmäßig erreicht Monaten uptime (die ich nur neu starten, wenn kritische Sicherheits-patches Auswirkungen auf meine abgespeckte und gehärteten Debian-Linux ausgegeben werden, was wirklich nicht oft geschieht) und auf die Anwendungen nie abstürzt (das macht es sehr unwahrscheinlich, dass es ein hardware-Problem auf, dass die Maschine [mehr dazu unten])
gleichen Anwendung funktioniert perfekt auf diesem Rechner unter einer JVM 1.5 unter der gleichen Last (dies ist, wie Teste ich die app: ich einfach starten Sie es unter eine 1.5 VM)
gleichen Anwendung funktioniert einwandfrei auf mehr als ein hundert clients Maschine unter den gleichen (riesigen) laden (noch nie abgestürzt, einmal auf Windows + JVM 1.5 oder 1.6 und noch nie abgestürzt, einmal auf OS X + JVM 1.5 oder 1.6 [ein Absturz würde bedeuten, eine sofortige Anruf von der client -])
anderen Anwendung auf der gleichen Maschine und gleichen 1.6.0_17 oder JVM 1.6.0_18 niemals zum Absturz bringen (zum Beispiel habe ich zwei Instanzen von IntelliJ IDEA zu laufen, wie zwei unterschiedliche Benutzer auf die gleiche Maschine und Sie nicht Abstürzen)
Maschine ist getestet mit memtest "regelmäßig" (vor der Installation eines neuen OS, mit dem letzten passiert ist, wenn ich installiert Debian Lenny nicht so lang her)

Hier ist die reproduzierbare-on-demand-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)

Starten Sie die app, führen Sie eine "Flut von Daten", ein paar Sekunden warten...

Dann immer, für 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

(beachten Sie, dass die Zeile " [libjvm.also+0x4bc080] " ist konsequent für 1.6.0_17 bei jedem SIGSEGV)

oder für 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

(beachten Sie, dass die Zeile "[libjvm.also+0x4d88f0]" ist konsequent für 1.6.0_18 bei jedem SIGSEGV)

Das problem ist, dass die log-Datei enthält proprietäre Informationen
das kann nicht geteilt werden.

Reproduktion eines "kleinen test case", dass das Problem reproduzieren, ist nicht realistisch, entweder: es ist so ähnlich wie die Frage oben verlinkten, dies geschieht nur, wenn eine "Flut von Daten" gefüttert, um die app.

Beachten Sie, dass die genau die gleiche Anwendung, auf genau der gleichen hardware, mit genau der gleichen JVM-aber eine andere version von Linux (hatte ich Debian Etch bisher) NICHT ausgelöst hat, dass SIGSEGV einmal.

Aber das bedeutet nicht, dass die JVM ist nicht Schuld: es könnte immer noch eine JVM-Problem.

Sollte ich das melden und wie? (halten Sie im Verstand, dass das schreiben eine "reproduzierbare kleinen test case" ist wahnhafte und dass das Protokoll enthält proprietäre Informationen, die nicht zugespielt werden). Sollte ich einfach Bearbeiten Sie das Protokoll und schicken Sie es?

Was ist das Verfahren für die Meldung solcher reproduzierbare SIGSEGV, wenn dein log enthält proprietäre Informationen, und wenn ein Testfall zu reproduzieren, das Problem ist nicht realistisch machbar?

Hat einer von Euch Erfolg haben, öffnen so ein Fehler und dann sehen Sie es gelöst in einer späteren Java-Version?

Glaubst du, es ist gut "für die Java-community" zu melden so ein Problem, oder ich darf nur nicht die Mühe, weil es nicht wichtig ist?

Tut dies, gelten noch immer mit der neuesten version von Java? Berücksichtigen Sie auch die Verwendung der IBM Java oder JRocket.
Ravn Andersen: ich werde prüfen, später und heute Abend hier berichten
Ravn Andersen: Gerade heruntergeladene JRE-version: 6.0_25-b06. Genau die gleiche Absturz :-/
Und IBM Java?..
Auch, geschieht dies auf einer der offiziell unterstützten Linux-Plattformen?

InformationsquelleAutor SyntaxT3rr0r | 2010-02-19

6

Ich habe ähnliches problem, ein Upgrade auf JDK 1.6_18 und es scheint gelöst mit den folgenden Optionen:
```
-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
```
Habe ich noch nicht überprüfen (es ist eine Produktionsumgebung), aber ich denke, der Fehler lag an zwei Gründen:

1) Falsche Einstellung über den Haufen und/oder Permanenten Speicherplatz werden zu lassen (ich denke, dass JDK 1.6 benötigt mehr Speicherplatz im heap und permanent als frühere JVM-Versionen) verursacht einen OutOfMemoryError, aber

2) in der falschen ursprüngliche Einstellung jemand schrieb
```
-XX:+HeapDumpOnOutOfMemoryError="/tmp"
```
und nicht
```
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath="/tmp"
```
also wahrscheinlich JVM war nicht in der Lage zu schreiben, der heapdump und wir haben SIGSEGV nur (frühere Versionen geschrieben heap-dump in das Arbeitsverzeichnis).

Überprüfen -server -XX:+UseParallelGC -XX:-UseGCOverheadLimit Möglichkeiten zu. Ich denke, dass das spielen mit der VM-Parameter ist nicht ein workaround, aber der richtige Ansatz, auch weil der garbage collector (nicht nur) veränderte sich zwischen 1,5 und 1,6.

cool, deine erste Antwort auf SO zu einem war meine Frage 🙂 alles Versucht, was Sie vorgeschlagen, aber es ist immer noch abstürzt. Es gibt keine Anzeichen für einen OutOfMemoryError, versuchte ich mit einem benutzerdefinierten JLabel Anzeige der Speicherauslastung. Offenbar keine PermGen Problem auch nicht.
dein post hat mich zum nachdenken gebracht... ich bin mit einem Linux-Computer mit mehr als einem proc und mehr als 2GB mem, also Java ist standardmäßig auf den -server-Modus. Interessanterweise genug, wenn ich Gewalt "-client" es gibt keinen Absturz mehr... (ich bin noch nicht sicher, was zu tun mit meinem reproduzierbare SIGSEGV aber es ist trotzdem interessant)

InformationsquelleAutor glenti
5

Das problem ist, dass die log-Datei
enthält proprietäre Informationen, die
nicht geteilt werden kann. Reproduktion eines "kleinen
test case" , das Problem zu reproduzieren
ain ' T realistisch, entweder

Wenn Sie nicht auf Sonne mit einer reproduzierbaren Testfall, werden Sie nicht einmal anschauen. Die Chance stehen gut, dass Sie es ignorieren auch wenn Sie einen brauchbaren Testfall. Der bug submission-Prozess an der Sonne, Blätter eine Menge zu wünschen übrig.

Sollte ich das melden und wie?

Wenn Sie können nicht kommen mit einer reproduzierbaren Testfall, nicht die Mühe. Wenn Sie können nicht das Problem zu reproduzieren, was Sie von Ihnen erwarten?

Beachten Sie, dass die genau die gleiche Anwendung,
auf exakt der gleichen hardware, mit
genau das gleiche aber eine andere JVM
die Linux-version (ich hatte Debian Etch
bisher) NICHT ausgelöst hat,
SIGSEGV einmal.

Funktioniert es auf einer anderen box die gleiche hardware und die gleiche version von Linux?

Ich bin mir sicher, dass der Kauf Unterstützung bekommt Sie VIEL mehr Aufmerksamkeit. Wie viel, hängt von der Stufe, die Sie kaufen.
ah verdammt... ich könnte dd meine hd auf einen anderen ein und versuchen damit, die mit den gleichen Linux-kernel, Konfiguration und JVMs, um zu sehen, ob der SIGSEGV ist auch reproduzierbar, aber was du schreibst ist es ziemlich deprimierend. Ein test-Fall würde bedeuten, Hunderte von Megabyte an Daten senden. Naja, wenn es reproduzierbar auf jeder hardware, vielleicht sollte ich einfach Schiff die Festplatte oder eine Bootfähige CD, die das problem reproduzieren können 🙂 (ich bin halb-ernst) Was ist mit dem OpenJDK? Würde alles anders sein wenn ich könnte zuverlässig reproduzieren diese unter die OpenJDK-7 ?
Sie sagen, es gibt propriertary Informationen in der log-Datei. Schreiben Sie einen parser oder etwas zu "banalize" diese Daten, und senden Sie dann das logfile auf Sonne ?

InformationsquelleAutor Kevin
1

Wenn es hilft, den bug submission link in Ihrer crash-Bericht hat dieses Haftungsausschlusses:

Außerdem, Sun Microsystems respektiert Ihren Wunsch nach Privatsphäre. Erhobenen personenbezogenen Daten werden von diesem Programm werden nicht verkauft, verschenkt oder gemeinsam mit externen Organisationen zur Sonne. Wir verwenden diese Daten für die Kommunikation mit Ihnen zu klären, Fragen in Bezug auf den Bericht, den Sie vorgelegt und/oder den status des Berichts. Die Themen, über die Sie Bericht kann zur Verfügung gestellt werden, um andere JDC-Mitglieder oder Sun-Kunden, die jedoch Ihre persönlichen Daten werden vertraulich behandelt. Wenn Sie nicht vertraut sind mit den oben genannten Bedingungen, bitte nicht drücken Sie den Absenden-button. Wenn Sie Fragen haben, wenden Sie sich bitte an unsere Datenschutzerklärung.

Persönlich würde ich es melden, wenn es möglich war, mit der hand über das code-segment in Frage, mit logs, wenn die Daten nicht zu empfindlich (vielleicht Daten können maskiert oder verschleiert in den logs?).

Ist es unmöglich für Sie, um wirklich beurteilen zu können, ob der Fehler "wichtig" ist oder nicht für andere es sei denn, Sie wissen, was tatsächlich verursacht. Reporting es könnte der erste Schritt in der Sonne, haben die Ingenieure herauszufinden, die Ursache von etwas ernstes.

b: yup, dachte über das clearing werden die Dateinamen in die hs_err_...log. Ich werde sehen, ob ein Proguarded version löst auch der Absturz und dann kann ich auch geschickt die verborgenen .Glas + Daten, damit ist das Problem zu reproduzieren. Immer noch meinen Kopf kratzen.

InformationsquelleAutor matt b
0

Die erste Frage die Sie sich stellen sollten ist:
- Bin ich durch eine offiziell unterstützte Linux-distribution?
Wenn nicht, wechseln Sie zu einer.

Wenn Sie sind, dann melden Sie ihn an Sonne!

offiziell unterstützt vom wem? Von Sonne meinst du? Ich bin mit der stabilsten Linux-distribution, die jemals gemacht wurden, dass eine Menge Leute hassen, weil es immer langsam mit den neuesten flulls & pfeift & Glocken und dass andere Menschen wie mich lieben, denn es ist rock stabil solide: Debian 🙂
Unterstützt durch das Unternehmen, das produziert hat die JVM, die Sie verwenden. Sonne nicht sagen, dass Ihre Java läuft auf jedem Linux-distribution in der Existenz, aber Sie sagen, dass Sie "Unterstützung" der Verteilungen aufgeführt, die auf java.sun.com/javase/6/webnotes/install/... (wobei "support" bedeutet auch überlegen, hören bugreports). Debian ist nicht da, aber Ubuntu ist. Stattdessen verwenden.
Oh ok, ich sehe, was du meinst (danke für den link)... sagte, Dass Ubuntu eigentlich Debian: Debian ist der höchst ANGESEHENE distribution, die von Systemadministratoren und Befugnisse, die viel von der Realen Welt [TM] Server, ich bin nicht der Wechsel zu einer anderen Linux-Distribution 😉 , sagte, das Problem ist nicht die SIGSEGV (ich habe workarounds), aber was zu tun... 🙂

InformationsquelleAutor Thorbjørn Ravn Andersen

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.