![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ-Index] [Zum Kapitel 1 - Einführung in OpenBSD] [Zum Kapitel 3 - Mit OpenBSD durchstarten]
Die offizielle Webseite des OpenBSD-Projekts findest du unter http://www.OpenBSD.org/de/.
Hier kannst du viele wertvolle Informationen über alle Aspekte des OpenBSD-Projekts finden.
Das OpenBSD Journal ist ein Neuigkeiten- und Meinungsportal, das auf OpenBSD fokussiert ist.
OpenBSDsupport.org ist eine Seite, die benutzerverwaltete Dokumentationen von unterschiedlicher Qualität sammelt, jedoch häufig Themen abdeckt, die in dieser FAQ oder in anderen offiziellen Dokumenten nicht behandelt werden.
Viele Benutzer haben Webseiten und Homepages mit OpenBSD-spezifischen Informationen erstellt. Wie mit allem im Internet wird eine gute Suchmaschine dein Leben einfacher machen, was genauso für eine gesunde Dosis Skepsis gilt. Und, wie immer: Gib niemals blindlings Befehle in deinen Computer ein, die du nicht verstehst.
Das OpenBSD-Projekt betreibt mehrere populäre Mailinglisten, die Benutzer abonnieren und lesen sollten. Um sich in eine Mailingliste einzuschreiben, schicke eine E-Mail an majordomo@openbsd.org. Diese Adresse ist ein automatischer Abonnementservice. Im Textkörper der Nachricht solltest du - in einer einzigen Zeile - das entsprechende »subscribe«-Kommando für die gewünschte Liste anführen. Zum Beispiel:
subscribe announce
Der Mailinglistendienst wird dir antworten und dich um Bestätigung bitten, sodass andere nicht in der Lage sind, dich mit einer Flut von unerwünschten E-Mails zu überschwemmen. Diese Nachricht wird verschiedene Optionen für die Bestätigung beinhalten; dazu gehören ein Webseitenlink auf den Listen-Server, die Möglichkeit des Antwortens auf die Bestätigungs-E-Mail oder das Antworten mittels einer E-Mail zu majordomo@openbsd.org. Nutze die Methode, die für dich am einfachsten ist. Du wirst feststellen, dass alle drei Varianten eine einmalige und zeitlich begrenzte Identitätsnummer beinhalten (z. B. A56D-70D4-52C3), um zu gewährleisten, dass tatsächlich du die Person bist, die die Einschreibung in die Mailingliste angefordert hat (das ist echtes »opt-in«).
Nach deiner Bestätigung wirst du sofort in die Liste eingetragen und der Mailinglistendienst wird dich über deine erfolgreiche Einschreibung benachrichtigen.
Um dich von einer Liste abzumelden, schicke wiederrum eine Nachricht an majordomo@openbsd.org. Sie könnte etwa so aussehen:
unsubscribe announce
Solltest du irgendwelche Schwierigkeiten mit dem Mailinglistensystem haben, so lies bitte zunächst die Anweisungen und Hinweise, die man sich durch das Senden einer E-Mail mit dem Textkörper »help« an majordomo@openbsd.org zusenden lassen kann.
Deine Einschreibung in die OpenBSD-Mailinglisten kann ebenfalls über das Webinterface auf http://lists.openbsd.org verwaltet werden.
Einige der beliebteren OpenBSD-Mailinglisten sind:
Bevor du eine Frage an misc oder eine andere Mailingliste sendest, überprüfe bitte zunächst die Archive, da die meisten Fragen schon wiederholt gestellt wurden. Auch wenn es vielleicht das erste Mal ist, dass dir das Problem auffällt, so mögen andere Mitglieder der Mailingliste dieselbe Frage mehrfach in der Vorwoche gesehen haben, und es nicht gerade mögen, sie erneut zu sehen. Falls du eine Frage stellst, die möglicherweise mit Hardware zu tun hat, so füge immer eine dmesg(8) mit ein!
Du kannst verschiedene Archive, andere Mailinglisten-Richtlinien und weitere Informationen auf der Mailinglistenseite finden.
Eine inoffizielle Mailingliste, die insbesondere für neue Anwender von OpenBSD interessant sein könnte, ist die Liste mit dem Namen OpenBSD Newbies.
OpenBSD wird von umfangreicher Dokumentation in Form von Handbuchseiten begleitet. Erhebliche Anstrengungen werden unternommen, um sicherzustellen, dass diese Handbuchseiten aktuell und akkurat sind. In allen Fällen werden die Handbuchseiten als maßgebliche Informationsquelle für OpenBSD angesehen.
Um auf die Handbuchseiten zugreifen zu können, muss das man52.tgz-Dateiset installiert worden sein.
Es folgt eine Liste der nützlichsten Handbuchseiten für Anfänger:
Einführung
Du kannst alle OpenBSD-Handbuchseiten im Web via http://www.openbsd.org/cgi-bin/man.cgi genauso finden, wie auf deinem eigenen Computer, wenn du das Dateiset man52.tgz installierst.
Im Allgemeinen kannst du die Handbuchseite eines dir namentlich bekannten Befehls erreichen, indem du »man Befehl« eingibst. Zum Beispiel zeigt dir »man vi« die Handbuchseite des Editors vi an. Solltest du den genauen Namen des Befehls nicht wissen, oder sollte »man Befehl« nicht die gewünschte Handbuchseite aufzeigen, so kannst du mittels »apropos irgendwas« oder »man -k irgendwas« nach dem Namen des Befehls suchen, wobei »irgendwas« ein Wort sein sollte, das einigermaßen wahrscheinlich im Titel der von dir gesuchten Handbuchseite enthalten sein sollte. Zum Beispiel:
# apropos "time zone" tzfile (5) - time zone information zdump (8) - time zone dumper zic (8) - time zone compiler
Die Zahlen in Klammern bezeichnen den Abschnitt des Handbuchs, in welchem die Seite gefunden werden kann. In einigen Fällen wirst du gleichlautende Handbuchseiten in verschiedenen Abschnitten des Handbuchs finden. Nimm zum Beispiel an, dass du das Format der Konfigurationsdateien des Dämons cron nachschlagen möchtest. Wenn du erst einmal den Abschnitt weißt, in welchem sich die gewünschte Seite befindet, so kannst du »man n Befehl« ausführen, wobei n die Abschnittsnummer des Handbuchs bezeichnet.
# man -k cron cron (8) - clock daemon crontab (1) - maintain crontab files for individual users crontab (5) - tables for driving cron # man 5 crontab
Eine gedruckte Fassung einer Handbuchseite zu besitzen kann nützlich sein. Hier ist die Anleitung, wie man die druckbare Version einer Handbuchseite erzeugt.
Diese Dateien finden sich im gesamten Quelltextbaum. Die Handbuchseiten befinden sich unformatiert im Baum und werden sehr oft, durch Nutzung von CVS, aktualisiert. Um sich diese Seiten anzusehen:
# mandoc <file> | more
Dies ist nützlich, um die Handbuchseite ohne nicht-druckbare Zeichen zu
erhalten.
Beispiel:
# man <Befehl> | col -b
Beachte, dass <Datei> die Quelltextdatei der Handbuchseite sein muss (wahrscheinlich eine Datei, die mit einer Zahl endet, z. B. tcpdump.8). Die Postscriptversionen der Handbuchseiten sehen sehr gut aus. Sie können ausgedruckt oder am Bildschirm mit einem Programm wie gv (GhostView) betrachtet werden. GhostView kannst du in unserer Paketkollektion finden. Benutze die folgenden mandoc(1)-Befehlsoptionen, um eine Postscriptversion aus einer OpenBSD-Systemhandbuchseite zu erstellen:
# mandoc -Tps <file> > outfile.ps
Für Leute, die ihr System aus dem Quelltext erzeugen, gibt es einige Optionen, um Handbuchseiten zu erzeugen. Diese Optionen können in /etc/mk.conf (vielleicht muss diese Datei erst angelegt werden) geschrieben und somit in die Systemerzeugung integriert werden. Eine besonders gebräuchliche Option ist, komprimierte Handbuchseiten zu erzeugen, um Plattenspeicher sparen zu können. Diese Dateien können unter Verwendung des Befehls »man« auf üblichen Weg angezeigt werden. Um diese Option zu setzen, füge Folgendes in /etc/mk.conf ein:
Eine andere nützliche Option ist es, die Systemerzeugung die Handbuchseiten sowohl im PostScript-Format als auch als ASCII-Text generieren zu lassen. Dafür muss die Option MANPS=yes in /etc/mk.conf gesetzt werden. Siehe mk.conf(5) für weitere Einzelheiten.MANZ=yes
Einige Teile der Dokumentation für OpenBSD liegen in Form von Info-Dateien vor, welche sich typischerweise im Verzeichnis /usr/share/info befinden. Dies ist eine alternative Form der Dokumentation, die von GNU angeboten wird. Viele dieser Dateien sind aktueller als die Handbuchseiten von GNU und können mit dem Befehl info(1) betrachtet werden. Um zum Beispiel die Informationen über den GNU-Compiler gcc(1) anzusehen, gib Folgendes ein:
Nach der Verwendung von info wirst du unsere Handbuchseiten zu schätzen wissen!# info gcc
Die standardmäßige Konfigurationsdatei für xterm(1) zeigt keine farbigen Handbuchseiten an. Um farbige Ausgabe zu erhalten, kopiere die Datei /etc/X11/app-defaults/XTerm-color in dein Heimatverzeichnis und benenne sie in ».Xdefaults« um. Sei vorsichtig, damit du nicht irgendwelche aktuellen Einstellungen in einer eventuell bereits existierenden ».Xdefaults« überschreibst. Die Datei beinhaltet alle Einstellungen, um Farbe im XTerm zu aktivieren. Allerdings müssen drei Zeilen auskommentiert werden, bevor dies funktioniert:
Der Rest der Datei erlaubt dir, Farben für verschiedene Einstellungen zu wählen. Die für die Handbuchseiten relevanten sind:!*VT100*colorULMode: on !*VT100*underLine: off !*VT100*colorBDMode: on
Dies produziert ziemlich höllenmäßig aussehende Handbuchseiten, also ändere sie nach deinen Bedürfnissen: dürfen wir Rot für »colorUL« und Magenta für »colorBD« empfehlen? Es ist ebenfalls ein Handbuchseitenbetrachter für X11 namens xman verfügbar, welcher eine alternative (grafische) Oberfläche für die Handbuchseiten bietet. Schau in die Handbuchseiten für xterm und xman für weitere Informationen.*VT100*colorUL: yellow *VT100*colorBD: white
Falls du eine eigene Handbuchseite für ein selbst entwickeltes Programm schreiben möchtest, so findest du ein praktisches Nachschlagewerk in mdoc(7).
Bevor du schließlich einen Fehlerbericht einsendest, lies bitte http://www.openbsd.org/de/report.html.
Sachgemäße Berichterstattung von Fehlern ist eine der wichtigsten Verantwortlichkeiten von Endbenutzern. Sehr detaillierte Informationen werden benötigt, um die meisten schwierigen Fehler zu diagnostizieren. Entwickler erhalten häufig Fehlerberichte via E-Mails wie der Folgenden:
From: joeuser@example.com To: bugs@openbsd.org Subject: HELP!!! I have a PC and it won't boot!!!!! It's a 486!!!!! |
Hoffentlich verstehen die meisten Menschen, warum solche Fehlerberichte grundsätzlich gelöscht werden. Jeder Fehlerbericht sollte detaillierte Informationen enthalten. Wenn Joe User wirklich die Untersuchung seines Fehlers erwartet hätte, dann hätte er oder sie mehr Informationen angeboten... Etwas wie das Folgende:
From: smartuser@example.com
To: bugs@openbsd.org
Subject: 3.3-beta panics on a SPARCStation2
OpenBSD 3.2 installed from an official CD-ROM installed and ran fine
on this machine.
After doing a clean install of 3.3-beta from an FTP mirror, I find the
system randomly panics after a period of use, and predictably and
quickly when starting X.
This is the dmesg output:
OpenBSD 3.3-beta (GENERIC) #9: Mon Mar 17 12:37:18 MST 2003
deraadt@sparc.openbsd.org:/usr/src/sys/arch/sparc/compile/GENERIC
real mem = 67002368
avail mem = 59125760
using 200 buffers containing 3346432 bytes of memory
bootpath: /sbus@1,f8000000/esp@0,800000/sd@1,0
mainbus0 (root): SUNW,Sun 4/75
cpu0 at mainbus0: CY7C601 @ 40 MHz, TMS390C602A FPU; cache chip bug
- trap page uncached
cpu0: 64K byte write-through, 32 bytes/line, hw flush cache enabled
memreg0 at mainbus0 ioaddr 0xf4000000
clock0 at mainbus0 ioaddr 0xf2000000: mk48t02 (eeprom)
timer0 at mainbus0 ioaddr 0xf3000000 delay constant 17
auxreg0 at mainbus0 ioaddr 0xf7400003
zs0 at mainbus0 ioaddr 0xf1000000 pri 12, softpri 6
zstty0 at zs0 channel 0 (console i/o)
zstty1 at zs0 channel 1
zs1 at mainbus0 ioaddr 0xf0000000 pri 12, softpri 6
zskbd0 at zs1 channel 0: reset timeout
zskbd0: no keyboard
zstty2 at zs1 channel 1: mouse
audioamd0 at mainbus0 ioaddr 0xf7201000 pri 13, softpri 4
audio0 at audioamd0
sbus0 at mainbus0 ioaddr 0xf8000000: clock = 20 MHz
dma0 at sbus0 slot 0 offset 0x400000: rev 1+
esp0 at sbus0 slot 0 offset 0x800000 pri 3: ESP100A, 25MHz, SCSI ID 7
scsibus0 at esp0: 8 targets
sd0 at scsibus0 targ 1 lun 0: <SEAGATE, ST1480 SUN0424, 8628> SCSI2 0/direct fixed
sd0: 411MB, 1476 cyl, 9 head, 63 sec, 512 bytes/sec, 843284 sec total
sd1 at scsibus0 targ 3 lun 0: <COMPAQPC, DCAS-32160, S65A> SCSI2 0/direct fixed
sd1: 2006MB, 8188 cyl, 3 head, 167 sec, 512 bytes/sec, 4110000 sec total
le0 at sbus0 slot 0 offset 0xc00000 pri 5: address 08:00:20:13:10:b9
le0: 16 receive buffers, 4 transmit buffers
cgsix0 at sbus0 slot 1 offset 0x0: SUNW,501-2325, 1152x900, rev 11
wsdisplay0 at cgsix0
wsdisplay0: screen 0 added (std, sun emulation)
fdc0 at mainbus0 ioaddr 0xf7200000 pri 11, softpri 4: chip 82072
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
root on sd0a
rootdev=0x700 rrootdev=0x1100 rawdev=0x1102
This is the panic I got when attempting to start X:
panic: pool_get(mclpl): free list modified: magic=78746572; page 0xfaa93000;
item addr 0xfaa93000
Stopped at Debugger+0x4: jmpl [%o7 + 0x8], %g0
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb> trace
pool_get(0xfaa93000, 0x22, 0x0, 0x1000, 0x102, 0x0) at pool_get+0x2c0
sosend(0x16, 0xf828d800, 0x0, 0xf83b0900, 0x0, 0x0) at sosend+0x608
soo_write(0xfac0bf50, 0xfac0bf70, 0xfac9be28, 0xfab93190, 0xf8078f24, 0x0)
at soo_write+0x18
dofilewritev(0x0, 0xc, 0xfac0bf50, 0xf7fff198, 0x1, 0xfac0bf70) at
dofilewritev+0x12c
sys_writev(0xfac87508, 0xfac9bf28, 0xfac9bf20, 0xf80765c8, 0x1000, 0xfac0bf70)
at sys_writev+0x50
syscall(0x79, 0xfac9bfb0, 0x0, 0x154, 0xfcffffff, 0xf829dea0) at syscall+0x220
slowtrap(0xc, 0xf7fff198, 0x1, 0x154, 0x1, 0xfac87508) at slowtrap+0x1d8
ddb> ps
PID PPID PGRP UID S FLAGS WAIT COMMAND
27765 8819 29550 0 3 0x86 netio xconsole
1668 29550 29550 0 3 0x4086 poll fvwm
15447 29550 29550 0 3 0x44186 poll xterm
8819 29550 29550 35 3 0x4186 poll xconsole
1238 29550 29550 0 3 0x4086 poll xclock
29550 25616 29550 0 3 0x4086 pause sh
1024 25523 25523 0 3 0x40184 netio XFree86
*25523 25616 25523 35 2 0x44104 XFree86
25616 30876 30876 0 3 0x4086 wait xinit
30876 16977 30876 0 3 0x4086 pause sh
16977 1 16977 0 3 0x4086 ttyin csh
5360 1 5360 0 3 0x84 select cron
14701 1 14701 0 3 0x40184 select sendmail
12617 1 12617 0 3 0x84 select sshd
27515 1 27515 0 3 0x184 select inetd
1904 1 1904 0 2 0x84 syslogd
9125 1 9125 0 3 0x84 poll dhclient
7 0 0 0 3 0x100204 crypto_wa crypto
6 0 0 0 3 0x100204 aiodoned aiodoned
5 0 0 0 3 0x100204 syncer update
4 0 0 0 3 0x100204 cleaner cleaner
3 0 0 0 3 0x100204 reaper reaper
2 0 0 0 3 0x100204 pgdaemon pagedaemon
1 0 1 0 3 0x4084 wait init
0 -1 0 0 3 0x80204 scheduler swapper
Thank you!
|
In report.html finden sich weitere Informationen für die Erstellung und Einsendung von Fehlerberichten. Detaillierte Informationen über deine Hardware sind absolut notwendig, wenn du glaubst, dass der Fehler irgendwie mit deiner Hardware oder deiner Hardwarekonfiguration zusammenhängen könnte. Normalerweise ist die Ausgabe von dmesg(8) in dieser Hinsicht ausreichend. Eine detaillierte Beschreibung deines Problems ist notwendig. Dmesg beschreibt deine Hardware, der Text erklärt, warum Smart User denkt, das System sei defekt (3.2 lief noch bestens), wie dieser Absturz erzeugt wurde (als er X startete) und die Ausgabe der Debuggerbefehle »ps« und »trace«. In diesem Fall hat Smart User die Informationen bereitgestellt, die er über eine serielle Konsole bekommen hat. Wenn du das nicht tun kannst, bist du gezwungen, mittels Stift und Papier die Informationen vom Absturz aufzuzeichnen. (Das Beispiel war im Übrigen ein echtes Problem und die Informationen des obigen Reports führten dazu, dass dieses Problem, das Sun4c-Systeme betraf, behoben werden konnte.)
Wenn Smart User ein funktionierendes OpenBSD-System gehabt hätte, von dem aus er einen Fehlerbericht hätte abschicken wollen, so hätte er sendbug(1) verwendet, um den Fehlerbericht zu verfassen und zum GNATS-Problemerfassungssystem zu senden. Logischerweise kannst du sendbug(1) nicht verwenden, wenn dein System nicht startet, jedoch solltest du es nutzen, wann immer dies möglich ist. In jedem Fall musst du zusätzliche Informationen darüber, was passiert ist, über die exakte Konfiguration deines Systems und wie man das Problem reproduzieren kann, bereitstellen. Der Befehl sendbug(1) setzt voraus, das E-Mail erfolgreich über das Internet versandt werden kann. Beachte, dass der Mailserver ein auf dem spamd(8) basierendes »Greylisting« verwendet, sodass es eine halbe Stunde oder länger dauern kann, bevor dein Fehlerbericht akzeptiert wird. Zeige also bitte etwas Geduld.
Nach der Einsendung eines Fehlerberichts per sendbug(1) wirst du vielleicht von Entwicklern kontaktiert werden, die dich nach weiteren Informationen fragen oder dich bitten, Korrekturroutinen zu testen. Des Weiteren kannst du auch die Archive der Mailingliste bugs@openbsd.org überwachen - Details dazu gibt es auf der Mailinglistenseite.
Die »Panik-Meldung« verloren?
Unter bestimmten Umständen kannst du die ersten Meldungen der Paniknachricht
verlieren, die den Grund für die Panik angeben.
Dies ist eine sehr wichtige Meldung, daher solltest du sie ebenfalls berichten.
Du kannst sie wiederbekommen, indem du den Befehl »show panic« im ddb>
wie folgt verwendest:
ddb> show panic 0: kernel: page fault trap, code=0 ddb> |
In diesem Fall war die Panikmeldung »Kernel: page fault trap, code=0«.
Besonderer Hinweis für SMP-Systeme:
Du solltest einen »Trace« von jedem Prozessor als Teil deines Berichts
holen:
ddb{0}> trace
pool_get(d05e7c20,0,dab19ef8,d0169414,80) at pool_get+0x226
fxp_add_rfabuf(d0a62000,d3c12b00,dab19f10,dab19f10) at fxp_add_rfabuf+0xa5
fxp_intr(d0a62000) at fxp_intr+0x1e7
Xintr_ioapic0() at Xintr_ioapic0+0x6d
--- interrupt ---
idle_loop+0x21:
ddb{0}> machine ddbcpu 1
Stopped at Debugger+0x4: leave
ddb{1}> trace
Debugger(d0319e28,d05ff5a0,dab1bee8,d031cc6e,d0a61800) at Debugger+0x4
i386_ipi_db(d0a61800,d05ff5a0,dab1bef8,d01eb997) at i386_ipi_db+0xb
i386_ipi_handler(b0,d05f0058,dab10010,d01d0010,dab10010) at i386_ipi_handler+0x
4a
Xintripi() at Xintripi+0x47
--- interrupt ---
i386_softintlock(0,58,dab10010,dab10010,d01e0010) at i386_softintlock+0x37
Xintrltimer() at Xintrltimer+0x47
--- interrupt ---
idle_loop+0x21:
ddb{1}>
|
Wiederhole »machine ddbcpu x« gefolgt von »trace« für jeden einzelnen Prozessor deiner Maschine.
Ein typischer Kernelabsturz von OpenBSD sieht wie folgt aus (Dinge, die besonders beachtet werden sollten, sind mit fetter Schrift markiert):
kernel: page fault trap, code=0 Stopped at _pf_route+0x263: mov 0x40(%edi),%edx ddb> |
Das erste Kommando, das vom ddb>-Prompt aufgerufen werden sollte, ist »trace« (siehe ddb(4) für Details):
ddb> trace _pf_route(e28cb7e4,e28bc978,2,1fad,d0b8b120) at _pf_route+0x263 _pf_test(2,1f4ad,e28cb7e4,b4c1) at _pf_test+0x706 _pf_route(e28cbb00,e28bc978,2,d0a65440,d0b8b120) at _pf_route+0x207 _pf_test(2,d0a65440,e28cbb00,d023c282) at _pf_test+0x706 _ip_output(d0b6a200,0,0,0,0) at _ip_output+0xb67 _icmp_send(d0b6a200,0,1,a012) at _icmp_send+0x57 _icmp_reflect(d0b6a200,0,1,0,3) at _icmp_reflect+0x26b _icmp_input(d0b6a200,14,0,0,d0b6a200) at _icmp_input+0x42c _ipv4_input(d0b6a200,e289f140,d0a489e0,e289f140) at _ipv4_input+0x6eb _ipintr(10,10,e289f140,e289f140,e28cbd38) at _ipintr+0x8d Bad frame pointer: 0xe28cbcac ddb> |
Dies zeigt uns, welcher Funktionsaufruf zu dem Absturz führte.
Um die exakte Zeile C-Quelltext zu finden, die diesen Absturz verursacht hat,
kannst du das Folgende tun:
Finde die Quelltextdatei, in welcher die abstürzende Funktion definiert ist.
In diesem Beispiel würde das pf_route() in sys/net/pf.c sein.
Übersetze diese Quelldatei mit Debug-Informationen neu:
# cd /usr/src/sys/arch/$(uname -m)/compile/GENERIC/ # rm pf.o # DEBUG=-g make pf.o |
Dann benutze objdump(1), um die »disassemblierte« Form zu gewinnen:
# objdump --line --disassemble --reloc pf.o >pf.dis |
Suche in der Ausgabe nach dem Funktionsnamen (pf_route in unserem Beispiel):
# grep "<_pf_route>:" pf.dis 00007d88 <_pf_route>: |
Nimme diese hexadezimale Nummer und addiere den »offset« der Zeile
»Stopped at«:
0x7d88 + 0x263 == 0x7feb.
blättere weiter bis zu dieser Zeile
(die »Assembler«-Instruktion sollte jener der Zeile »Stopped at« entsprechen),
dann nach oben zu der nächsten C-Zeilennummer:
# more pf.dis
/usr/src/sys/arch/i386/compile/GENERIC/../../../../net/pf.c:3872
7fe7: 0f b7 43 02 movzwl 0x2(%ebx),%eax
7feb: 8b 57 40 mov 0x40(%edi),%edx
7fee: 39 d0 cmp %edx,%eax
7ff0: 0f 87 92 00 00 00 ja 8088 <_pf_route+0x300>
|
Es ist also präzise Zeile 3872 von pf.c, die den Absturz verursachte:
# cat -n pf.c | head -n 3872 | tail -n 1
3872 if ((u_int16_t)ip->ip_len <= ifp->if_mtu) {
|
Es ist anzumerken, das der Kernel, der die Absturz-Ausgabe produziert hat und die Objekt-Datei für »objdump« aus exakt derselben Quelldatei her übersetzt worden sein müssen, ansonsten würden die »offsets« nicht übereinstimmen.
Wenn du sowohl die ddb> »trace«-Ausgabe, als auch die relevanten »objdump«-Sektionen bereitstellen könntest, so wäre dies sehr hilfreich.
[FAQ-Index] [Zum Kapitel 1 - Einführung in OpenBSD] [Zum Kapitel 3 - Mit OpenBSD] durchstarten
![[zurück]](../../images/back.gif){kind=small}
www@openbsd.org