Probleme während der Debugger-Ausführung

Folgende Probleme stehen mit dem Kernel-Debugger in Zusammenhang.

x86: Unerwartetes SIGTRAP-Signal verursacht ein Aufhängen des dbx-Debuggers (6546562 )

Wenn der dbx-Debugger unter Solaris 10 auf x86-Plattformen zur Fehlersuche in einem Programm verwendet wird, das Signale mit Signalbehandlungsroutinen auslöst bzw. liefert, kann dbx ein unerwartetes SIGTRAP-Signal vom Kernel empfangen, das ein Aufhängen des Debuggers verursacht. Diese Situation kann auftreten, wenn sich dbx im Einzelschrittmodus befindet, zu einem Abbruchpunkt gelangt, Laufzeitprüfdaten (RTC) sammelt oder andere Aktivitäten ausführt, die Signal-Trapping verwenden.

In einigen Fällen zeigt dbx einen Warnhinweis auf ein unerwartetes SIGTRAP-Signal an, wenn er sich aufhängt. Beispiel:

dbx: internal warning: unexpected SIGTRAP!

In anderen Fällen meldet dbx den Empfang eines SEGV-Signals. Beispiel:

signal SEGV (no mapping at the fault address) in main at line 29 in file "test.c"

In diesem Fall zeigt dbx den Warnhinweis auf ein unerwartetes SIGTRAP-Signal an, wenn der Benutzer den Befehl cont -sig SEGV zur Fortsetzung der Ausführung mit dem SEGV-Signal eingibt.

Dieser Fehler tritt unter Solaris 10 auf x86-Plattformen nach der Installation des Kernel-Patches 127112 auf.

Problemumgehung: Installieren Sie das Kernel-Patch 127112 nicht bzw. deinstallieren Sie es, falls es bereits installiert wurde. Weitere Informationen zu diesem Fehler finden Sie auf der Sun Studio Support News-Seite unter http://developers.sun.com/sunstudio/support/news/index.jsp.

SPARC: Probleme mit dem Debugger dbx beim Verarbeiten von 64-Bit-Objekten (6347707)

Der Debugger dbx bricht beim Verarbeiten bestimmter 64-Bit-Programme und -Bibliotheken mit einem Speicherzugriffsfehler ab. Auf die normale Nutzung dieser 64-Bit-Objekte hat dieses Problem jedoch keine Auswirkungen. Sie sehen dann eine Fehlermeldung der Art:

dbx: interner Fehler: Signal SIGBUS (invalid address alignment)

Problemumgehung: Verwenden Sie stattdessen entweder den Debugger mdb oder die Solaris Dynamic Tracing-Funktion. Mit diesen Alternativen ist eine Diagnose von Prozessen möglich, die die 64-Bit-Objekte verwenden.

Möglicherweise hängt sich das System in einer Endlosschleife auf, wenn die Haupt-CPU gewechselt wird (4405263)

Ein System, auf dem der Solaris-Kernel-Debugger zum Debuggen eines Livesystems ausgeführt wird, hängt sich möglicherweise in einer Endlosschleife unvollständiger Fehlermeldungen auf. Diese Endlosschleife tritt auf, wenn die Haupt-CPU des OpenBoot PROMs ausgetauscht wird. Ein Zurücksetzen des Systems stellt den Systembetrieb wieder her. Die Spuren des ursprünglichen Fehlers gehen dabei jedoch verloren. Infolgedessen können sie keine Diagnose des Vorfalls vornehmen.

Problemumgehung: Wenn sich das System auf der PROM-Ebene befindet, wird die ok-Eingabeaufforderung von OpenBoot angezeigt. Bei einem System mit mehreren CPUs wird der ok-Eingabeaufforderung eine in geschweifte Klammern eingeschlossene Zahl vorangestellt. Diese Zahl gibt die aktive CPU im System an. Um Ihre Debug-Sitzung auszuführen, während sich das System auf PROM-Ebene befindet, führen Sie folgende Schritte durch.

1. Erhöhen Sie pil auf f, indem Sie folgenden Befehl eingeben:

   {0} ok h# 0f pil!

2. Wechseln Sie mit dem Befehl switch-cpu selektiv von der derzeit aktiven CPU zu anderen CPUs. Um beispielsweise von CPU #0 zu CPU #1 zu wechseln, geben Sie folgenden Befehl ein:

   (0) ok 1 switch-cpu

   Der ok-Eingabeaufforderung wird nun die Zahl der CPU vorangestellt, zu der Sie gewechselt haben.

   {1} ok

3. Führen Sie Ihren Debugger aus.

4. Am Ende Ihrer Debugger-Sitzung geben Sie einen Befehl reset-all ein, um das System wieder in die normale Verwendung zurückzuführen.

Stellen Sie sicher, dass Sie das System auf die neueste Version von OpenBoot PROM aktualisieren.