[FAQ Index] [Naar Sectie 1 - Inleiding tot OpenBSD] [Naar Sectie 3 - Beginnen met OpenBSD]

2 - OpenBSD leren kennen

Inhoudsopgave

• 2.1 - Webpagina's
• 2.2 - Mailinglijsten
• 2.3 - Manual Pagina's
• 2.4 - Bugs Rapporteren

2.1 - Interessante Webpagina's

De officiële website voor het OpenBSD project is te vinden op: http://www.OpenBSD.org.

Veel waardevolle informatie is hier te vinden omtrent alle aspecten van het OpenBSD project.

Het OpenBSD Journal is een OpenBSD-gerichte nieuws- en opiniesite.

OpenBSDsupport.org is een site die "door gebruikers onderhouden" documentatie van variabele kwaliteit verzamelt, maar die vaak onderwerpen behandelt die niet in deze FAQ of andere officiële documentatie staan.

Veel gebruikers hebben sites en pagina's met OpenBSD-specifieke informatie opgezet. Zoals met alles op het Internet, zal een goede zoekrobot u het leven gemakkelijker maken, net als een gezonde dosis scepsis. Zoals altijd, voer niet blindelings commando's in uw computer die u niet begrijpt.

2.2 - Mailinglijsten

Het OpenBSD project onderhoudt verscheidene populaire mailinglijsten waar gebruikers zich op inschrijven en die ze volgen. Om u in te schrijven op een mailinglijst, stuurt u een e-mail naar majordomo@openbsd.org. Dat adres is een automatische inschrijvingsdienst. In het tekstgedeelte van uw bericht moet u op één enkele lijn een inschrijvingscommando invoeren voor de lijst waarop u zich wil inschrijven. Bijvoorbeeld:

subscribe announce

De lijstverwerker zal u antwoorden, met de vraag om bevestiging van uw voornemen om de lijst te vervoegen, zodat anderen u niet kunnen inschrijven op een overvloed van ongewenste e-mail. Het bericht zal instructies bevatten voor verschillende manieren om te bevestigen, zoals een list server webpagina link, het bevestigingsbericht beantwoorden of antwoorden naar majordomo@openbsd.org. Gebruik gelijk welke methode die u het best uitkomt. U zal merken dat alle drie de technieken een uniek en in de tijd beperkt identificatienummer met zich meebrengen, zoals A56D-70D4-52C3, opnieuw om er zeker van te zijn dat werkelijk u de persoon bent die deze inschrijving op de mailinglijst heeft aangevraagd (dit is echt "opt-in").

Zodra u uw bedoeling om in te schrijven heeft bevestigd, zal u onmiddellijk toegevoegd worden aan de lijst, en de lijstverwerker zal u laten weten dat u goed en wel toegevoegd bent.

Om u uit te schrijven van een lijst, stuurt u opnieuw een e-mail bericht naar majordomo@openbsd.org. Dit zou er zo kunnen uitzien:

unsubscribe announce

Als u moeilijkheden ondervindt met het mailinglijstsysteem, leest u dan alstublieft eerst het hulpbestand dat kan bekomen worden door een e-mail bericht te sturen naar majordomo@openbsd.org met "help" in het tekstgedeelte van het bericht.

Uw inschrijving op de OpenBSD mailinglijsten kan ook beheerd worden via de web interface op http://lists.openbsd.org

Enkele van de populaire OpenBSD mailinglijsten zijn:

• announce - Belangrijke aankondigingen. Dit is een lijst met kleine omvang.
• security-announce - Aankondigingen van beveiligingsproblemen. Dit is een lijst met kleine omvang.
• misc - Algemene vragen en antwoorden van gebruikers. Dit is de meest actieve lijst, en zou de standaard lijst moeten zijn voor de meeste vragen.
• bugs - Bugs ontvangen via sendbug(1) en discussies erover.
• source-changes - Geautomatiseerde mailing van wijzigingen aan de CVS broncode. Telkens wanneer een ontwikkelaar een wijziging commit in de OpenBSD source tree, stuurt CVS een kopie van het (gewoonlijk korte) commit bericht via deze lijst.
• ports - Discussie van de OpenBSD Ports Tree.
• ports-changes - Geautomatiseerde mailing van ports-specifieke CVS source tree wijzigingen.
• advocacy - Discussie over OpenBSD aanbeveling, en onderwerpen die gewoon te off-topic zijn voor misc.

Alvorens een vraag te stellen op misc of gelijk welke andere mailinglijst, kijk alstublieft eerst in de archieven, omdat de meeste van de gewoonlijke vragen reeds verscheidene malen gesteld zijn. Terwijl het misschien de eerste keer is dat u een probleem of vraag tegenkomt, hebben anderen op de mailinglijst dezelfde vraag misschien al verscheidene keren gezien de voorbije week, en vinden zij het misschien niet leuk ze nog eens te zien. Als u een vraag stelt die mogelijk verband houdt met hardware, voeg er dan steeds een dmesg(8) bij!

Voor verschillende archieven, richtlijnen van andere mailinglijsten en meer informatie kan u terecht op de mailinglijst pagina.

Een niet-officiële mailinglijst die misschien interessant is voor nieuwe gebruikers van OpenBSD en Unix is de OpenBSD Newbies lijst.

2.3 - Manual Pagina's

OpenBSD komt met uitgebreide documentatie in de vorm van manual pagina's. Er wordt aanzienlijke moeite gedaan om ervoor te zorgen dat man pagina's up-to-date en nauwkeurig zijn. In elk geval worden de man pagina's beschouwd als de gezaghebbende bron van informatie voor OpenBSD.

Om de manual pagina's te benaderen, zorgt u ervoor dat u de man52.tgz bestandenset geïnstalleerd hebt.

Hieronder volgt een lijst van enkele van de nuttigste manual pagina's voor nieuwe gebruikers:

Van start gaan

• afterboot(8) - dingen om na te kijken na de eerste volledige boot.
• help(1) - hulp voor nieuwe gebruikers en beheerders.
• hier(7) - layout van bestandssystemen.
• man(1) - toon de on-line manual pagina's.
• intro(1) - inleiding tot algemene commando's, zie ook de inleiding tot andere delen van de manual: intro(2), intro(3), intro(4) (note: intro(4) is platform-specifiek), intro(5), intro(6), intro(7), intro(8), and intro(9).
• adduser(8) - commando om nieuwe gebruikers toe te voegen.
• vipw(8) - bewerk het master password bestand.
• disklabel(8) - lees en schrijf disk pack label.
• reboot, halt(8) - herstart of stop het systeem.
• shutdown(8) - sluit het systeem af op een gegeven ogenblik.
• dmesg(8) - toon de kernel boot boodschappen nog eens.
• sudo(8) - log niet in als root, maar voer commando's uit als root.
• mg(1) - emacs-achtige tekstverwerker.

• boot(8) - system bootstrapping procedures.
• boot_config(8) - hoe de kernel configuratie bij het booten veranderen.
• gcc-local(1) - OpenBSD-specifieke wijzigingen aan gcc(1).
• ifconfig(8) - configureer netwerkinterface-parameters.
• login.conf(5) - formaat van de login class configuratiebestanden.
• netstat(1) - toon de netwerkstatus.
• release(8) - bouw een OpenBSD release.
• sendbug(1) - stuur een probleemrapport (PR) over OpenBSD naar een centrale ondersteuningssite.
• style(9) - OpenBSD kernel broncode stijlgids.
• sysctl(8) - kernel status weergeven of instellen.

U kan alle OpenBSD man pagina's op het web vinden op http://www.openbsd.org/cgi-bin/man.cgi maar ook op uw computer als u de man52.tgz bestandenset installeert.

In het algemeen, als u de naam van een commando of een manual pagina kent, kan u ze lezen door "man commando" uit te voeren. Bijvoorbeeld: "man vi" om over de vi editor te lezen. Als u de naam van het commando niet kent, of als "man commando" de manual pagina niet vindt, kan u de manual pagina databank doorzoeken door "apropos iets" of "man -k iets" uit te voeren, waarbij "iets" een woord is dat waarschijnlijk in de titel van de manual pagina die u zoekt, zou kunnen voorkomen. Bijvoorbeeld:

# apropos "time zone"
tzfile (5) - time zone information
zdump (8) - time zone dumper
zic (8) - time zone compiler

De cijfers tussen haakjes geven de sectie van de manual aan waarin die pagina kan gevonden worden. In sommige gevallen kan u manual pagina's met identieke namen terugvinden die in afzonderelijke secties van de manual voorkomen. Stel bijvoorbeeld dat u het formaat van de configuratiebestanden voor de cron daemon wil kennen. Zodra u de sectie van de manual weet voor de pagina die u wenst, kan u "man n commando" uitvoeren, waarin n het sectienummer van de manual is.

# man -k cron
cron (8) - clock daemon
crontab (1) - maintain crontab files for individual users
crontab (5) - tables for driving cron
# man 5 crontab

Voor velen kan het nuttig zijn een papieren kopie van de manual pagina te hebben. Hier zijn de richtlijnen om een afdrukbare kopie van een manual pagina te maken.

Hoe toon ik een man pagina bronbestand (i.e. een waarvan de bestandsnaam eindigt in een cijfer, zoals tcpdump.8)?

Deze worden doorheen de src tree gevonden. De man pagina's worden in de tree ongeformatteerd teruggevonden, en vaak worden zij, door gebruik van CVS, aangepast. Om deze pagina's te bekijken, doet u gewoon:

# mandoc <file> | more

Hoe verkrijg ik een plain man pagina zonder formattering of controletekens?

Dit is nuttig om de man pagina meteen, zonder niet-afdrukbare tekens te bekomen.
Voorbeeld:

# man <command> | col -b

Hoe kan ik van een man pagina een PostScript kopie bekomen die klaar is om af te drukken?

Merk op dat <file> het man pagina bronbestand moet zijn (waarschijnlijk een bestand dat op een cijfer eindigt, bv. tcpdump.8). De PostScript versies van de man pagina's zien er erg goed uit. Ze kunnen afgedrukt worden of op het scherm bekeken worden met een programma als gv (GhostView). GhostView vindt u terug in onze packages verzameling. Gebruik de volgende mandoc(1) commando-opties om een PostScript versie van een OpenBSD systeem man pagina te bekomen:

# mandoc -Tps <file> > outfile.ps

Hoe genereer ik gecomprimeerde kopieën van de man pagina's?

Voor mensen die hun systeem van broncode bouwen, zijn er een aantal opties die verband houden met de manier waarop man pagina's gebouwd worden. Deze opties kunnen in /etc/mk.conf geplaatst worden (het zou kunnen dat u dit bestand moet aanmaken) en worden in rekening gebracht tijdens systeem builds. Een heel nuttige optie is het genereren van gecomprimeerde man pagina's om schijfruimte te besparen. Deze kunnen op de normale manier bekeken worden, met het man commando. Om dit in te stellen, voegt u het volgende toe aan /etc/mk.conf:

MANZ=yes

Wat zijn info bestanden?

Sommige van de documentatie van OpenBSD komt in de vorm van info bestanden, typisch bewaard in /usr/share/info. Dit is een alternatieve vorm van documentatie voorzien door GNU. Veel van deze bestanden zijn meer up-to-date dan de manual pagina's voorzien door GNU, en kunnen bekeken worden met het info(1) commando. Om bijvoorbeeld informatie te bekijken over de GNU compiler, gcc(1), typt u:

# info gcc

Hoe krijg ik man pagina's in kleur op XTerm?

Het standaard configuratiebestand voor xterm(1) toont geen gekleurde man pagina's. Om gekleurde uitvoer te krijgen, kopieert u het bestand /etc/X11/app-defaults/XTerm-color naar uw home directory, en hernoemt u het naar ".Xdefaults". Wees voorzichtig en overschrijf uw huidige instellingen niet in ".Xdefaults". Dit bestand bevat alle instellingen die u nodig hebt om kleur in te schakelen in XTerm. Er moeten echter drie lijnen uit commentaar gehaald worden alvorens dit kan werken:

!*VT100*colorULMode: on
!*VT100*underLine: off
!*VT100*colorBDMode: on

*VT100*colorUL: yellow
*VT100*colorBD: white

Hoe schrijf ik mijn eigen manual pagina?

Mocht u uw eigen man pagina willen schrijven voor een toepassing die u hebt geschreven, dan is een handige referentiegids beschikbaar in mdoc(7).

2.4 - Bugs Rapporteren

Tenslotte, alvorens gelijk welk bug rapport op te sturen, leest u alstublieft eerst http://www.openbsd.org/report.html.

Juiste bug rapportering is een van de belangrijkste verantwoordelijkheden van eindgebruikers. Heel gedetaillerede informatie is vereist om een diagnose te stelen van de meest ernstige bugs. Ontwikkelaars krijgen geregeld bug-rapporten als dit via e-mail:

From: joeuser@example.com To: bugs@openbsd.org Subject: HELP!!! Ik heb een PC en hij wil niet starten!!!!! Het is een 486!!!!!

Hopelijk zien de meeste mensen in waarom zulke meldingen terstond verwijderd worden. Alle bug-rapporten zouden gedetailleerde informatie moeten bevatten. Als Gebruiker Joe echt verwacht had dat iemand zijn bug zou helpen vinden, zou hij of zij meer informatie verschaft hebben... iets als dit:

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!

Zie report.html voor meer informatie over het maken en opsturen van bug reports. Gedetailleerde informatie over uw hardware is nodig als u denkt dat de bug op gelijk welke manier verband zou kunnen houden met uw hardware of hardware configuratie. Gewoonlijk volstaat een dmesg(8) uitvoer in dit verband. Een gedetailleerde omschrijving van uw probleem is nodig. U zal merken dat de dmesg de hardware beschreef, de tekst uitlegde waarom Smart User dacht dat het systeem niet gebroken was (3.2 draaide naar behoren), hoe zijn crash tot stand kwam (door X te starten), en de uitvoer van de "ps" en "trace" commando's van de debugger. In dit geval verschafte Smart User uitvoer, bekomen via een seriële console; als u dat niet kan doen, zal u pen en papier moeten gebruiken om de crash te registreren. (Dit was een echt probleem en de informatie in het bovenstaande rapport heeft helpen leiden tot een herstelling van dit probleem dat Sun4c systemen trof.)

Als Smart User een werkend OpenBSD systeem had vanaf welk hij een bug-rapport wou versturen, zou hij de sendbug(1) utility gebruikt hebben om zijn bug-rapport naar het GNATS problem tracking systeem te sturen. Vanzelfsprekend kan u sendbug(1) niet gebruiken als uw systeem niet wil starten, maar gebruik het wanneer het mogelijk is. U zal nog steeds gedetailleerde informatie moeten meegeven over wat er gebeurde, de precieze configuratie van uw systeem, en hoe het probleem gereproduceerd kan worden. Het sendbug(1) commando vereist dat uw systeem elektronische mail kan versturen op het Internet. Merk op dat de mail server spamd(8) gebaseerde greylisting gebruikt, dus het kan een half uur ofzo duren voor de mail server uw bug-rapport aanvaardt, wees alstublieft geduldig.

Na het doorsturen van een bug-rapport met sendbug(1), kunt u door de ontwikkelaars benaderd worden voor bijkomende informatie of voor het testen van patches. U kunt ook de archieven van de bugs@openbsd.org mailinglijst volgen, details op de mailinglijst pagina.

Hoe vergaar ik meer nuttige informatie voor ontwikkelaars?

De "Panic message" kwijt?
In sommige omstandigheden kan u het allereerste bericht van een panic kwijt raken, die net de reden voor de panic geeft. Dit is een heel belangrijk bericht, dus u wil het zeker ook rapporteren. U kan dit terugkrijgen door het "show panic" commando in ddb> als volgt:

ddb> show panic 0: kernel: page fault trap, code=0 ddb>

In dit geval was de panic string "Kernel: page fault trap, code=0"

Speciale nota voor SMP systemen:
U kunt best van elke processor een "trace" opvragen voor uw rapport:

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}>

Herhaal de "machine ddbcpu x" gevolgd door "trace" voor elke processor in uw machine.

Hoe verzamel ik meer informatie van een kernel crash?

Een typische kernel crash op OpenBSD zou er zo uit kunnen zien: (dingen om op te letten zijn vet gemarkeerd)

kernel: page fault trap, code=0 Stopped at _pf_route+0x263: mov 0x40(%edi),%edx ddb>

Het eerste commando om te typen op de ddb> prompt is "trace" (zie ddb(4) voor de 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>

Dit vertelt ons welke functie calls hebben geleid tot de crash.

Om de exacte regel C-code te achterhalen die de crash veroorzaakte, kunt u het volgende doen:
Vind het bron-bestand waarin de crashende functie is gedefinieerd. In dit voorbeeld zou dat pf_route() zijn in sys/net/pf.c. Hercompileer dat bron-bestand met debug informatie:

# cd /usr/src/sys/arch/$(uname -m)/compile/GENERIC/ # rm pf.o # DEBUG=-g make pf.o

Gebruik vervolgens objdump(1) om de disassembly te verkrijgen:

# objdump --line --disassemble --reloc pf.o >pf.dis

Zoek in de uitvoer naar de functienaam (pf_route in ons voorbeeld):

# grep "<_pf_route>:" pf.dis 00007d88 <_pf_route>:

Neem dit eerste hexadecimale nummer en tel er de offset van de 'Stopped at' regel bij op: 0x7d88 + 0x263 == 0x7feb.
Scroll naar beneden naar deze regel (de assembler instructie zou overeen moeten komen met degene die werd genoemd in de 'Stopped at' regel), en dan naar boven naar de dichtsbijzijnde regel C-code:

# 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>

Het is dus precies regel 3872 van pf.c die crasht:

# cat -n pf.c | head -n 3872 | tail -n 1 3872 if ((u_int16_t)ip->ip_len <= ifp->if_mtu) {

Merk op dat de kernel die de crash-uitvoer produceerde en het object-bestand voor objdump gecompileerd moeten zijn vanaf precies hetzelfde bron-bestand, anders komen de offsets niet overeen.

Als u zowel de ddb> trace uitvoer en het relevante deel van de objdump aanlevert, dan is dat zeer hulpzaam.

[FAQ Index] [Naar Sectie 1 - Inleiding tot OpenBSD] [Naar Sectie 3 - Beginnen met OpenBSD]