Use correct syntax markup for shell
Approved by: carlavilla
This commit is contained in:
Li-Wen Hsu
parent
55c95407aa
commit
a9a9e66105
666 changed files with 17924 additions and 17924 deletions
|
|
@ -64,7 +64,7 @@ Vergleichen Sie [.filename]#/etc/fstab# oder man:swapinfo[8] für eine Liste der
|
|||
====
|
||||
Stellen Sie sicher, dass das in man:rc.conf[5] festgelegte `dumpdir` vor einem Kernel-Absturz vorhanden ist.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# mkdir /var/crash
|
||||
# chmod 700 /var/crash
|
||||
|
|
@ -85,7 +85,7 @@ In dem Fall, dass bereits eine Datei mit dem Namen [.filename]#vmcore.0# in [.fi
|
|||
|
||||
Falls Sie einen neuen Kernel testen, aber einen anderen starten müssen, um Ihr System wieder in Gang zu bringen, starten Sie es nur in den Singleuser-Modus, indem Sie das `-s`-Flag an der Boot-Eingabeaufforderung benutzen, und nehmen dann folgende Schritte vor:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# fsck -p
|
||||
# mount -a -t ufs # make sure /var/crash is writable
|
||||
|
|
@ -108,7 +108,7 @@ Sobald ein Speicherauszug zur Verfügung steht, ist es recht einfach nützliche
|
|||
|
||||
Um in den Debugger zu gelangen und mit dem Informationserhalt aus dem Speicherauszug zu beginnen, sind zumindest folgende Schritte nötig:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# cd /usr/obj/usr/src/sys/KERNCONF
|
||||
# kgdb kernel.debug /var/crash/vmcore.0
|
||||
|
|
@ -118,7 +118,7 @@ Sie können Fehler im Speicherauszug nach dem Absturz suchen, indem Sie die Kern
|
|||
|
||||
Dieser erste Speicherauszug ist aus einem 5.2-BETA-Kernel und der Absturz ist tief im Kernel begründet. Die Ausgabe unten wurde dahingehend bearbeitet, dass sie nun Zeilennummern auf der linken Seite einschließt. Diese erste Ablaufverfolgung (Trace) untersucht den Befehlszeiger (Instruction-Pointer) und beschafft eine Zurückverfolgung (Back-Trace). Die Adresse, die in Zeile 41 für den `list`-Befehl benutzt wird, ist der Befehlszeiger und kann in Zeile 17 gefunden werden. Die meisten Entwickler wollen zumindest dies zugesendet bekommen, falls Sie das Problem nicht selber untersuchen und beheben können. Falls Sie jedoch das Problem lösen, stellen Sie sicher, dass Ihr Patch seinen Weg in den Quellbaum mittels eines Fehlerberichts, den Mailinglisten oder ihres Privilegs, zu committen, findet!
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
1:# cd /usr/obj/usr/src/sys/KERNCONF
|
||||
2:# kgdb kernel.debug /var/crash/vmcore.0
|
||||
|
|
@ -214,7 +214,7 @@ Dieser erste Speicherauszug ist aus einem 5.2-BETA-Kernel und der Absturz ist ti
|
|||
|
||||
Diese nächste Ablaufverfolgung ist ein älterer Speicherauszug aus FreeBSD 2-Zeiten, aber ist komplizierter und zeigt mehr der `gdb`-Funktionen. Lange Zeilen wurden gefaltet, um die Lesbarkeit zu verbessern, und die Zeilen wurden zur Verweisung nummeriert. Trotzdem ist es eine reale Fehlerverfolgung (Error-Trace), die während der Entwicklung des pcvt-Konsolentreibers entstanden ist.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
1:Script started on Fri Dec 30 23:15:22 1994
|
||||
2:# cd /sys/compile/URIAH
|
||||
|
|
@ -323,7 +323,7 @@ Falls Ihr System regelmäßig abstürzt und und Sie bald keinen freien Speicherp
|
|||
|
||||
Die Untersuchung eines Speicherauszugs nach einem Kernel-Absturz mit einem grafischen Debugger wie `ddd` ist auch möglich (Sie müssen den package:devel/ddd[]-Port installieren, um den `ddd`-Debugger benutzen zu können). Nehmen Sie die `-k` mit in die `ddd`-Kommandozeile auf, die Sie normalerweise benutzen würden. Zum Beispiel:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ddd --debugger kgdb kernel.debug /var/crash/vmcore.0
|
||||
....
|
||||
|
|
@ -359,7 +359,7 @@ Sobald Ihr Kernel mit DDB startet, gibt es mehrere Wege, um in DDB zu gelangen.
|
|||
|
||||
Das zweite Szenario ist der Gang in den Debugger, sobald das System schon gestartet ist. Es gibt zwei einfache Wege dies zu erreichen. Falls Sie von der Eingabeaufforderung aus in den Debugger gelangen möchten, geben Sie einfach folgenden Befehl ab:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# sysctl debug.kdb.enter=1
|
||||
....
|
||||
|
|
@ -368,7 +368,7 @@ Das zweite Szenario ist der Gang in den Debugger, sobald das System schon gestar
|
|||
====
|
||||
Um eine schnelle Panic zu erzwingen, geben Sie das folgende Kommando ein:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# sysctl debug.kdb.panic=1
|
||||
....
|
||||
|
|
@ -390,7 +390,7 @@ der Kernel-Konfigurationsdatei hinzu und bauen/installieren Sie den Kernel neu.
|
|||
|
||||
Die DDB-Befehle ähneln grob einigen `gdb`-Befehlen. Das Erste, das Sie vermutlich tun müssen, ist einen Breakpoint zu setzen:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
break function-name address
|
||||
....
|
||||
|
|
@ -399,14 +399,14 @@ Zahlen werden standardmäßig hexadezimal angegeben, aber um sie von Symbolnamen
|
|||
|
||||
Um den Debugger zu verlassen und mit der Abarbeitung fortzufahren, geben Sie ein:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
continue
|
||||
....
|
||||
|
||||
Um eine Stack-Ablaufverfolgung zu erhalten, benutzen Sie:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
trace
|
||||
....
|
||||
|
|
@ -418,7 +418,7 @@ Beachten Sie, dass wenn Sie DDB mittels einer Schnelltaste betreten, der Kernel
|
|||
|
||||
Falls Sie einen Breakpoint entfernen möchten, benutzen Sie
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
del
|
||||
del address-expression
|
||||
|
|
@ -426,28 +426,28 @@ Falls Sie einen Breakpoint entfernen möchten, benutzen Sie
|
|||
|
||||
Die erste Form wird direkt, nachdem ein Breakpoint anschlug, angenommen und entfernt den aktuellen Breakpoint. Die zweite kann jeden Breakpoint löschen, aber Sie müssen die genaue Adresse angeben; diese kann bezogen werden durch:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
show b
|
||||
....
|
||||
|
||||
oder:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
show break
|
||||
....
|
||||
|
||||
Um den Kernel in Einzelschritten auszuführen, probieren Sie:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
s
|
||||
....
|
||||
|
||||
Dies springt in Funktionen, aber Sie können DDB veranlassen, diese schrittweise zu verfolgen, bis die passende Rückkehranweisung (Return-Statement) erreicht ist. Nutzen Sie hierzu:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
n
|
||||
....
|
||||
|
|
@ -459,7 +459,7 @@ Dies ist nicht das gleiche wie die ``next``-Anweisung von ``gdb``; es ist wie ``
|
|||
|
||||
Um Daten aus dem Speicher zu untersuchen, benutzen Sie (zum Beispiel):
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
x/wx 0xf0133fe0,40
|
||||
x/hd db_symtab_space
|
||||
|
|
@ -469,14 +469,14 @@ x/s stringbuf
|
|||
|
||||
für Word/Halfword/Byte-Zugriff und Hexadezimal/Dezimal/Character/String-Ausgabe. Die Zahl nach dem Komma ist der Objektzähler. Um die nächsten 0x10 Objekte anzuzeigen benutzen Sie einfach:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
x ,10
|
||||
....
|
||||
|
||||
Gleichermaßen benutzen Sie
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
x/ia foofunc,10
|
||||
....
|
||||
|
|
@ -485,7 +485,7 @@ um die ersten 0x10 Anweisungen aus `foofunc` zu zerlegen (disassemble) und Sie z
|
|||
|
||||
Um Speicher zu verändern benutzen Sie den Schreibbefehl:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
w/b termbuf 0xa 0xb 0
|
||||
w/w 0xf0010030 0 0
|
||||
|
|
@ -495,28 +495,28 @@ Die Befehlsoption (`b`/`h`/`w`) legt die Größe der Daten fest, die geschrieben
|
|||
|
||||
Falls Sie die aktuellen Register wissen möchten, benutzen Sie:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
show reg
|
||||
....
|
||||
|
||||
Alternativ können Sie den Inhalt eines einzelnen Registers ausgeben mit z.B.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
p $eax
|
||||
....
|
||||
|
||||
und ihn bearbeiten mit:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
set $eax new-value
|
||||
....
|
||||
|
||||
Sollten Sie irgendeine Kernel-Funktion aus DDB heraus aufrufen wollen, geben Sie einfach ein:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
call func(arg1, arg2, ...)
|
||||
....
|
||||
|
|
@ -525,28 +525,28 @@ Der Rückgabewert wird ausgegeben.
|
|||
|
||||
Für eine Zusammenfassung aller laufenden Prozesse im Stil von man:ps[1] benutzen Sie:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
ps
|
||||
....
|
||||
|
||||
Nun haben Sie herausgefunden, warum Ihr Kernel fehlschlägt, und möchten neu starten. Denken Sie daran, dass, abhängig von der Schwere vorhergehender Störungen, nicht alle Teile des Kernels wie gewohnt funktionieren könnten. Führen Sie eine der folgenden Aktionen durch, um Ihr System herunterzufahren und neu zu starten:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
panic
|
||||
....
|
||||
|
||||
Dies wird Ihren Kernel dazu veranlassen abzustürzen, einen Speicherauszug abzulegen und neu zu starten, sodass Sie den Kernspeicherauszug später auf höherer Ebene mit `gdb` auswerten können. Diesem Befehl muss normalerweise eine weitere `continue`-Anweisung folgen.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
call boot(0)
|
||||
....
|
||||
|
||||
Dürfte ein guter Weg sein, um das laufende System sauber herunterzufahren, alle Festplatten mittels `sync()` zu schreiben und schließlich, in manchen Fällen, neu zu starten. Solange die Festplatten- und Dateisystemschnittstellen des Kernels nicht beschädigt sind, könnte dies ein guter Weg für ein beinahe sauberes Abschalten sein.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
call cpu_reset()
|
||||
....
|
||||
|
|
@ -555,7 +555,7 @@ Dies ist der letzte Ausweg aus der Katastrophe und kommt beinahe dem Drücken de
|
|||
|
||||
Falls Sie eine kurze Zusammenfassung aller Befehle benötigen, geben Sie einfach ein:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
help
|
||||
....
|
||||
|
|
@ -571,7 +571,7 @@ GDB unterstützt _die Fehlersuche von einem entfernten System aus_ bereits einig
|
|||
|
||||
Sie sollten den Kernel im Zweifelsfall mit `config -g` konfigurieren, `DDB` in die Konfiguration aufnehmen und den Kernel, wie sonst auch, kompilieren. Dies ergibt, aufgrund der zusätzlichen Informationen zur Fehlersuche, eine umfangreiche Binärdatei. Kopieren Sie diesen Kernel auf das Zielsystem, entfernen Sie die Symbole zur Fehlersuche mit `strip -x` und starten Sie ihn mit der `-d`-Boot-Option. Stellen Sie die serielle Verbindung zwischen dem Zielsystem, welches "flags 80" für dessen sio-Gerät gesetzt hat, und dem Hostsystem, welches die Fehlersuche übernimmt, her. Nun wechseln Sie auf dem Hostsystem in das Bauverzeichnis des Ziel-Kernels und starten `gdb`:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% kgdb kernel
|
||||
GDB is free software and you are welcome to distribute copies of it
|
||||
|
|
@ -584,14 +584,14 @@ Copyright 1996 Free Software Foundation, Inc...
|
|||
|
||||
Stellen Sie die entfernte Sitzung zur Fehlersuche ein mit (angenommen, der erste serielle Port ist in Verwendung):
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
(kgdb) target remote /dev/cuaa0
|
||||
....
|
||||
|
||||
Jetzt geben Sie auf dem Zielsystem, welches noch vor Beginn der Gerätesuche in DDB gelangt ist, ein:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
Debugger("Boot flags requested debugger")
|
||||
Stopped at Debugger+0x35: movb $0, edata+0x51bc
|
||||
|
|
@ -600,14 +600,14 @@ db> gdb
|
|||
|
||||
DDB antwortet dann mit:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
Next trap will enter GDB remote protocol mode
|
||||
....
|
||||
|
||||
Jedesmal wenn Sie `gdb` eingeben, wird zwischen dem lokalen DDB und entfernten GDB umgeschaltet. Um einen nächsten Trap sofort zu erzwingen, geben Sie einfach `s` (step) ein. Ihr GDB auf dem Hostsystem erhält nun die Kontrolle über den Ziel-Kernel:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
Remote debugging using /dev/cuaa0
|
||||
Debugger (msg=0xf01b0383 "Boot flags requested debugger")
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue