Fehlerbehebung bei Java-Programmen
Java stellt eine Reihe von Informationen zur Verfügung, um Probleme mit Anwendungsprogrammen oder der Laufzeitumgebung zu beheben, insbesondere Stacktraces. Diese sollten einem Fehlerbericht beigefügt werden.
|
Diese Seite wurde aus der früheren Fedora Wiki-Dokumentation übernommen. Der Text wurde für die Veröffentlichung hier im Fedora Docs Portal überarbeitet, aber noch nicht auf technische Korrektheit geprüft. Wahrscheinlich
Wir freuen uns über Hinweise zur technischen Korrektheit. Wenn Sie mithelfen möchten, finden Sie Anweisungen in der README-Datei im Quellcode-Repository. Pull Requests werden auf https://forge.fedoraproject.org/docs/quick-docs akzeptiert Sobald die Seite korrekturgelesen und korrigiert ist, entfernen Sie diese Notiz. |
Diese Seite ist ein Anhang zur Seite Bereitstellen eines Stack-Traces. Das Abrufen von Stack-Traces aus Java-Software ist etwas komplizierter als bei den meisten anderen Softwareprojekten des Fedora-Projekts, da es zwei Arten von Stack-Traces gibt (Java und nativ).
Die zwei Arten von Java-Stacktraces
Die von libgcj erzeugten Stacktraces (d. h. die von der virtuellen Maschine während der Laufzeit erzeugten Stacktraces) umfassen alle in Java geschriebenen Programmteile und Bibliotheken sowie alle JNI- und CNI-Methoden – jedoch nicht Nicht-Java-Code, der von JNI- oder CNI-Methoden aufgerufen wird. Leider enthalten sie in der Regel auch keine Quellcodezeilennummern – selbst wenn vollständige Debugging-Informationen verfügbar sind. Die gute Nachricht ist jedoch, dass die libgcj-Stacktraces in gcc 4.1 mehr Informationen liefern werden – und es ist zu hoffen, dass diese Version rechtzeitig in Rawhide integriert wird, um in Fedora Core 5 enthalten zu sein.
Die von gdb erzeugten Stacktraces – die üblicherweise als „Backtraces“ bezeichnet werden – umfassen den gesamten nativen Code (unabhängig davon, ob es sich um C-Code oder in Maschinencode kompilierten Java-Code handelt). Bei interpretiertem Code zeigen sie jedoch nur die Aufrufe des Interpreters an, nicht aber, was genau interpretiert wird.
Daher sind weder Java-Stacktraces noch gdb-Backtraces für alle Situationen geeignet. Manchmal ist es notwendig, Java-Stacktraces, manchmal gdb-Backtraces und manchmal beides zu untersuchen.
Einen Java-Stacktrace aus einem Java-Programm erhalten
Manchmal geben Java-Programme beim Absturz oder anderen Fehlern Java-Stacktraces aus, entweder im Terminalfenster, von dem aus sie ausgeführt werden, oder in einer Protokolldatei.
Wenn Sie einen Stacktrace erhalten und dieser eine oder mehrere „Caused by:“-Klauseln enthält, beachten Sie bitte, dass die letzte „Caused By“-Klausel die wichtigste ist. Bitte posten Sie bei der Meldung eines Problems immer mindestens die letzte „Caused By“-Klausel (falls vorhanden).
Anwendungsspezifische Details
Eclipse
Wenn Sie Eclipse starten können, lässt sich das Fehlerprotokoll über das Menü Window und den Pfad Show View → Other → PDE Runtime → Error Log aufrufen. Ein Doppelklick auf einen Fehler öffnet ein Dialogfenster mit einem Stack-Trace, der sich direkt kopieren und in einen Fehlerbericht einfügen lässt.
Wenn Eclipse nicht startet, führen Sie es mit eclipse -consolelog aus, um das Protokoll in der Konsole auszugeben. Falls dies keine hilfreichen Informationen liefert, versuchen Sie es mit eclipse -consolelog -debug.
Wenn Sie keinen Java-Stack-Trace abrufen können
Wenn ein Java-Programm einfach abbricht, ohne einen Stack-Trace auszugeben – weder im Terminalfenster noch in einer Protokolldatei –, dann gilt Folgendes: Handelt es sich um ein nativ kompiliertes Programm oder erscheint unmittelbar vor dem Beenden die Meldung Aborted, Segmentation fault oder Illegal instruction, versuchen Sie, einen gdb-Backtrace zu erstellen (wie im nächsten Abschnitt beschrieben). Andernfalls ist ein gdb-Backtrace wahrscheinlich nicht hilfreich; reichen Sie in diesem Fall einfach einen Fehlerbericht ohne Stack-Trace ein.
Zukünftige Arbeiten: In der kommenden GCC-Version 4.1 ist ein SIGQUIT-Handler geplant, der es dem Benutzer ermöglicht, bei Bedarf Java-Stacktraces zu generieren. (Dies kann jedoch nicht für Abstürze verwendet werden, die das Programm beenden – es kann nur für bestimmte Fehler verwendet werden, die dazu führen, dass das Programm weiterläuft.)
Abrufen eines gdb-Backtraces aus einem Java-Programm
Zuerst müssen Sie die Seite „StackTraces“ lesen – bis zu dem Punkt, an dem gdb gestartet wird.
Da libgcj intern verschiedene Signale verwendet, müssen Sie gdb zunächst anweisen, einige davon zu ignorieren; geben Sie dazu die folgenden Befehle in gdb ein oder fügen Sie sie dort ein:
handle SIGHUP nostop print
handle SIGPWR nostop noprint
handle SIGXCPU nostop noprint
handle SIG32 nostop noprint
handle SIG33 nostop noprintgdb kann beim Laden der Debugging-Informationen für verschiedene Bibliotheken recht langsam sein (was die Startzeit von Programmen drastisch beeinträchtigen kann); um also eine angenehme Fortschrittsanzeige zu erhalten, sollten Sie zusätzlich Folgendes angeben:
set verbose onGeben Sie nun run (oder kurz r) ein und lesen Sie die Anweisungen auf der StackTraces-Seite weiter.
Ignorieren harmloser „Null Pointer Exceptions“ in gdb
Manchmal erzeugt Code eine oder mehrere Null Pointer Exceptions, die tatsächlich harmlos sind – oder zumindest für den Fehler, den Sie zu finden versuchen, irrelevant. (Nicht alle Null Pointer Exceptions sind harmlos oder irrelevant, aber einige schon.) Da gcj SIGSEGV verwendet, um Null Pointer Exceptions zu erkennen, können Sie auch Folgendes angeben:
handle SIGSEGV nostop noprintum gdb anzuweisen, SIGSEVs zu ignorieren, oder:
handle SIGSEGV nostop printum gdb anzuweisen, Sie über SIGSEVs zu informieren, sie aber ansonsten zu ignorieren.
Want to help? Learn how to contribute to Fedora Docs ›