Linux核心中的異常訊息：Oops詳解
- 王林轉載
- 2024-02-10 12:00:28657瀏覽
Oops是Linux核心中一種特殊的錯誤訊息，它用來表示核心發生了非致命的異常，如空指標解引用，非法記憶體訪問，除零錯誤等。 Oops的出現通常意味著核心中存在bug或驅動程式有問題，它會導致系統的不穩定或崩潰。在本文中，我們將介紹Linux內核的Oops的原理和特徵，包括Oops的格式，內容，原因，分類等，並舉例說明它們的使用方法和注意事項。
#在Linux核心開發中的Oops是什麼呢？其實，它和上面的解釋也沒什麼本質的差別，只不過說話的主角變成了Linux。當某些比較致命的問題出現時，我們的Linux核心也會抱歉的對我們說：「哎呦（Oops），對不起，我把事情搞砸了」。 Linux核心在發生kernel panic時會印出Oops訊息，把目前的暫存器狀態、堆疊內容、以及完整的Call trace都show給我們看，這樣就可以幫助我們定位錯誤。
下面，我們來看一個實例。為了突顯本文的主角–Oops，這個例子唯一的作用就是造一個空指標引用錯誤。
#include
#include
static int __init hello_init(void)
{
int *p = 0;
*p = 1;
return 0;
}
static void __exit hello_exit(void)
{
return;
}
module_init(hello_init);
module_exit(hello_exit);
MODULE_LICENSE("GPL");
很明顯，錯誤的地方就是第8行。
接下來，我們把這個模組編譯出來，再用insmod來插入到核心空間，正如我們預期的那樣，Oops出現了。
「
#[ 100.243737] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 100.244985] IP: [] hello_init 0x5/0x11 [hello]
[ 100.262266] *pde = 00000000
[ 100.288395] Oops: 0002 [#1] SMP
[ 100.305468] last sysfs file: /sys/devices/virtual/sound/timer/uevent
[ 100.325955] Modules linked in: hello( ) vmblock vsock vmmemctl vmhgfs acpiphp snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_er_ac97_codec ac97_bus snd_pcm_oss snd_er_ac97_codec ac97_bus snd_pcm_oss snd_er_yoss sq_pse_yosssq. idi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device ppdev psmouse serio_rawcon tileblit font bitblit softcursor snd parport_pc sound fb snd_page sndglit softcursor snd parport_pc sound fb snd_page_ocvm sod im agpgart shpchp lp parport floppy pcnet32 mii mptspi mptscsih mptbase scsi_transport_spi vmxnet
[ 100.472178] [ 100.494931] Pid: 1586, comm: insmod Not tainted (2.6.32-21-generic #32-Ubuntu) VMware Virtual Platform
###. ###[ 100.540018] EIP: 0060:[] EFLAGS: 00010246 CPU: 0### ###[ 100.562844] EIP is at hello_init 0x5/0x11 [hello] ###[ 100.584351] EAX: 00000000 EBX: fffffffc ECX: f82cf040 EDX: 00000001### ###[ 100.609358] ESI: f82cf040 EDI: 00000000 EBP: f1b9ff5c ESP: f1b9ff5c### ###[ 100.631467] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068### ###[ 100.657664] Process insmod (pid: 1586, ti=f1b9e000 task=f137b340 task.ti=f1b9e000)### ###[ 100.706083] Stack:### ###[ 100.731783] f1b9ff88 c0101131 f82cf040 c076d240 fffffffc f82cf040 0072cff4 f82d2000### ###[ 100.759324]fffffffc f82cf040 0072cff4 f1b9ffac c0182340 f19638f8 f137b340 f19638c0### ###[ 100.811396]00000004 09cc9018 09cc9018 00020000 f1b9e000 c01033ec 09cc9018 00015324########################################################################################################## ###[ 100.891922] Call Trace:### ###[ 100.916257] [] ? do_one_initcall 0x31/0x190### ###[ 100.943670] [] ? hello_init 0x0/0x11 [hello] ###[ 100.970905] [] ? sys_init_module 0xb0/0x210### ###[ 100.995542] [] ? syscall_call 0x7/0xb### ###[ 101.024087] Code: 05 00 00 00 00 01 00 00 00 5d c3 00 00 00 00 00 00 00 00 00 00#############################################################################################################################################################1## ###[ 101.079592] EIP: [] hello_init 0x5/0x11 [hello] SS:ESP 0068:f1b9ff5c### ###[ 101.134682] CR2: 0000000000000000### ###[ 101.158929] —[ end trace e294b69a66d752cb ]—### ######」########## ###Oops首先描述了這是一個什麼樣的bug，然後指出了發生bug的位置，即「IP: [] hello_init 0x5/0x11 [hello]」。 ### ###在這裡，我們需要用到一個輔助工具objdump來幫助分析問題。 objdump可以用來反彙編，指令格式如下：### #########「####### ###objdump -S hello.o###
”
下面是hello.o反汇编的结果，而且是和C代码混排的，非常的直观。
hello.o: file format elf32-i386
Disassembly of section .init.text:
00000000 :
#include
#include
static int __init hello_init(void)
{
0: 55 push %ebp
int *p = 0;
*p = 1;
return 0;
}
1: 31 c0 xor %eax,%eax
#include
#include
static int __init hello_init(void)
{
3: 89 e5 mov %esp,%ebp
int *p = 0;
*p = 1;
5: c7 05 00 00 00 00 01 movl $0x1,0x0
c: 00 00 00
return 0;
}
f: 5d pop %ebp
10: c3 ret
Disassembly of section .exit.text:
00000000 :
static void __exit hello_exit(void)
{
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: e8 fc ff ff ff call 4
return;
}
8: 5d pop %ebp
9: c3 ret
对照Oops的提示，我们可以很清楚的看到，出错的位置hello_init+0x5的汇编代码是：
5:c7 05 00 00 00 00 01 movl $0x1,0x0
这句代码的作用是把数值1存入0这个地址，这个操作当然是非法的。
我们还能看到它对应的c代码是：
*p = 1;
Bingo！在Oops的帮助下我们很快就解决了问题。
我们再回过头来检查一下上面的Oops，看看Linux内核还有没有给我们留下其他的有用信息。
“
Oops: 0002 [#1]
”
这里面，0002表示Oops的错误代码（写错误，发生在内核空间），#1表示这个错误发生一次。
Oops的错误代码根据错误的原因会有不同的定义，本文中的例子可以参考下面的定义（如果发现自己遇到的Oops和下面无法对应的话，最好去内核代码里查找）：
“
* error_code:
* bit 0 == 0 means no page found, 1 means protection fault
* bit 1 == 0 means read, 1 means write
* bit 2 == 0 means kernel, 1 means user-mode
* bit 3 == 0 means data, 1 means instruction”
有时候，Oops还会打印出Tainted信息。这个信息用来指出内核是因何种原因被tainted（直译为“玷污”）。具体的定义如下：
“
1: ‘G’ if all modules loaded have a GPL or compatible license, ‘P’ if any proprietary module has been loaded. Modules without a MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by insmod as GPL compatible are assumed to be proprietary.
2: ‘F’ if any module was force loaded by “insmod -f”, ‘ ‘ if all modules were loaded normally.
3: ‘S’ if the oops occurred on an SMP kernel running on hardware that hasn’t been certified as safe to run multiprocessor. Currently this occurs only on various Athlons that are not SMP capable.
4: ‘R’ if a module was force unloaded by “rmmod -f”, ‘ ‘ if all modules were unloaded normally.
5: ‘M’ if any processor has reported a Machine Check Exception, ‘ ‘ if no Machine Check Exceptions have occurred.
6: ‘B’ if a page-release function has found a bad page reference or some unexpected page flags.
7: ‘U’ if a user or user application specifically requested that the Tainted flag be set, ‘ ‘ otherwise.
8: ‘D’ if the kernel has died recently, i.e. there was an OOPS or BUG.
9: ‘A’ if the ACPI table has been overridden.
10: ‘W’ if a warning has previously been issued by the kernel. (Though some warnings may set more specific taint flags.)
11: ‘C’ if a staging driver has been loaded.
12: ‘I’ if the kernel is working around a severe bug in the platform firmware (BIOS or similar).”
基本上，這個Tainted資訊是留給核心開發者看的。使用者在使用Linux的過程中如果遇到Oops，可以把Oops的內容傳送給核心開發者去debug，核心開發者根據這個Tainted資訊大概可以判斷出kernel panic時核心運作的環境。如果我們只是debug自己的驅動，這個訊息就沒什麼意義了。
本文的這個例子非常簡單，Oops發生以後沒有造成宕機，這樣我們就可以從dmesg中查看到完整的資訊。但更多的情況是Oops發生的同時系統也會宕機，此時這些出錯訊息是來不及存入文件中的，關掉電源後就無法再看到了。我們只能用其他的方式來記錄：手抄或拍照。
還有更糟的情況，如果Oops資訊過多的話，一頁螢幕顯示不全，我們怎麼來查看完整的內容呢？第一種方法，在grub裡用vga參數指定更高的解析度以使螢幕可以顯示更多的內容。很明顯，這個方法其實解決不了太多的問題；第二種方法，使用兩台機器，把調試機的Oops資訊透過串口列印到宿主機的螢幕上。但現在大部分的筆記型電腦是沒有串列埠的，這個解決方法也有很大的限制；第三種方法，使用核心轉儲工具kdump把發生Oops時的記憶體和CPU暫存器的內容dump到一個檔案裡，之後我們再用gdb來分析問題。
開發核心驅動的過程中可能遇到的問題是千奇百怪的，調試的方法也是多種多樣，Oops是Linux核心給我們的提示，我們要用好它。
透過本文，我們了解了Linux核心的Oops的原理和特徵，它可以用來診斷和調試內核中的問題。我們應該根據實際需求選擇合適的工具，並遵循一些基本原則，如保存和分析Oops信息，使用符號表和源碼定位問題，使用模組參數和內核參數調整內核行為等。 Oops是Linux核心中常見的錯誤訊息，它可以反映核心的狀態和異常，也可以提升核心的品質和穩定性。希望本文能對你有所幫助與啟發。
以上是Linux核心中的異常訊息：Oops詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章！