JVM-Absturz aufgrund von SIGSEGV

  

Signalbeschreibung

     

SIGSEGV, SIGBUS, SIGFPE, SIGPIPE, SIGILL -   Wird in der Implementierung für die implizite Nullprüfung usw. verwendet.

     

SIGQUIT Thread-Dump-Unterstützung - Zum Ablegen von Java-Stack-Traces im Standardfehler-Stream. (Optional.)

     

SIGTERM, SIGINT, SIGHUP - Wird verwendet, um den Shutdown-Hook-Mechanismus (java.lang.Runtime.addShutdownHook) zu unterstützen, wenn die VM abnormal beendet wird. (Optional.)

     

SIGUSR1 - Wird in der Implementierung der Methode java.lang.Thread.interrupt verwendet. (Konfigurierbar.) Wird nicht mit Solaris 10 OS verwendet. Reserviert unter Linux.   SIGUSR2 Wird intern verwendet. (Konfigurierbar.) Wird nicht mit Solaris 10 OS verwendet.   SIGABRT Die HotSpot VM behandelt dieses Signal nicht. Stattdessen ruft es die Abbruchfunktion nach der fatalen Fehlerbehandlung auf. Wenn eine Anwendung dieses Signal verwendet, sollte sie den Prozess beenden, um die erwartete Semantik beizubehalten.

Das fatale Fehlerprotokoll zeigt an, dass der Absturz in einer systemeigenen Bibliothek aufgetreten ist. Möglicherweise liegt ein Fehler im systemeigenen Code oder im JNI-Bibliothekscode vor. Der Absturz könnte natürlich durch etwas anderes verursacht werden, aber die Analyse der Bibliothek und aller Kerndateien oder Absturzspeicherauszüge ist ein guter Ausgangspunkt.

In diesem Fall ist ein SIGSEGV mit einem Thread aufgetreten, der in der Bibliothek libdtagentcore.so ausgeführt wird. In einigen Fällen manifestiert sich ein Fehler in einer nativen Bibliothek als Absturz im Java-VM-Code. Stellen Sie sich den folgenden Absturz vor, bei dem ein JavaThread im Zustand _thread_in_vm fehlschlägt (was bedeutet, dass Java VM im Code ausgeführt wird)

• Wenn Sie in einer nativen Anwendungsbibliothek einen Absturz haben (wie in Ihrem Fall), können Sie möglicherweise den nativen Debugger an die Kerndatei oder den Absturzabzug anhängen, falls dieser verfügbar ist. Abhängig vom Betriebssystem ist der native Debugger dbx, gdb oder windbg.
• Ein anderer Ansatz besteht darin, mit der Option '-Xcheck: jni' in der Befehlszeile zu starten. Mit dieser Option können nicht alle Probleme mit dem JNI-Code gefunden werden, es kann jedoch helfen, eine erhebliche Anzahl von Problemen zu identifizieren.
• Wenn die native Bibliothek, in der der Absturz aufgetreten ist, Teil der Java-Laufzeitumgebung ist (z. B. awt.dll, net.dll usw.), ist es möglich, dass Sie auf einen Bibliotheks- oder API-Fehler gestoßen sind. Wenn Sie nach weiterer Analyse zu dem Schluss kommen, dass es sich um einen Bibliotheks- oder API-Fehler handelt, sammeln Sie möglichst viele Daten und reichen Sie einen Fehler oder einen Supportanruf ein.