定位Oops的具體代碼行

zx_wing

如果有個(gè)自動(dòng)objdump的功能就好了，因?yàn)榫幾g生成的.s文件都沒連接，好多地址都沒替換，有時(shí)候不好用

12013396

是打開編譯選項(xiàng) complie the kernel with debug info

但不知道，這個(gè)選項(xiàng)是什么時(shí)候出來的???

xiaojianredhat

(
來自Linus Torvalds的討論:
https://groups.google.com/group/ ... 41/ed9c0a0cfcd31111
又，http://kerneltrap.org/Linux/Further_Oops_Insights
)
     
        例如這樣的一個(gè)Oops：
                Oops: 0000 [#1] PREEMPT SMP  
                Modules linked in: capidrv kernelcapi isdn slhc ipv6 loop dm_multipath snd_ens1371 gameport snd_rawmidi snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd parport_pc floppy parport pcnet32 soundcore mii pcspkr snd_page_alloc ac i2c_piix4 i2c_core button power_supply sr_mod sg cdrom ata_piix libata dm_snapshot dm_zero dm_mirror dm_mod BusLogic sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd

                Pid: 1726, comm: kstopmachine Not tainted (2.6.24-rc3-module #2)
                EIP: 0060:[<c04e53d6>] EFLAGS: 00010092 CPU: 0
                EIP is at list_del+0xa/0x61
                EAX: e0c3cc04 EBX: 00000020 ECX: 0000000e EDX: dec62000
                ESI: df6e8f08 EDI: 000006bf EBP: dec62fb4 ESP: dec62fa4
                 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
                Process kstopmachine (pid: 1726, ti=dec62000 task=df8d2d40 task.ti=dec62000)
                Stack: 000006bf dec62fb4 c04276c7 00000020 dec62fbc c044ab4c dec62fd0 c045336c
                       df6e8f08 c04532b4 00000000 dec62fe0 c043deb0 c043de75 00000000 00000000
                       c0405cdf df6e8eb4 00000000 00000000 00000000 00000000 00000000
                Call Trace:
                 [<c0406081>] show_trace_log_lvl+0x1a/0x2f
                 [<c0406131>] show_stack_log_lvl+0x9b/0xa3
                 [<c04061dc>] show_registers+0xa3/0x1df
                 [<c0406437>] die+0x11f/0x200
                 [<c0613cba>] do_page_fault+0x533/0x61a
                 [<c06123ea>] error_code+0x72/0x78
                 [<c044ab4c>] __unlink_module+0xb/0xf
                 [<c045336c>] do_stop+0xb8/0x108
                 [<c043deb0>] kthread+0x3b/0x63
                 [<c0405cdf>] kernel_thread_helper+0x7/0x10
                 =======================
                Code: 6b c0 e8 2e 7e f6 ff e8 d1 16 f2 ff b8 01 00 00 00 e8 aa 1c f4 ff 89 d8 83 c4 10 5b 5d c3 90 90 90 55 89 e5 53 83 ec 0c 8b 48 04 <8b> 11 39 c2 74 18 89 54 24 08 89 44 24 04 c7 04 24 be 32 6b c0  
                EIP: [<c04e53d6>] list_del+0xa/0x61 SS:ESP 0068:dec62fa4
                note: kstopmachine[1726] exited with preempt_count 1
     
        1, 有自己編譯的vmlinux： 使用gdb
     
           編譯時(shí)打開complie with debug info選項(xiàng)。

           注意這行：
     
                EIP is at list_del+0xa/0x61
     
           這告訴我們，list_del函數(shù)有0x61這么大，而Oops發(fā)生在0xa處。 那么我們先看一下list_del從哪里開始：

                # grep list_del /boot/System.map-2.6.24-rc3-module
                c10e5234 T plist_del
                c10e53cc T list_del
                c120feb6 T klist_del
                c12d6d34 r __ksymtab_list_del
                c12dadfc r __ksymtab_klist_del
                c12e1abd r __kstrtab_list_del
                c12e9d03 r __kstrtab_klist_del

           于是我們知道，發(fā)生Oops時(shí)的EIP值是：

                c10e53cc + 0xa  == c10e53d6

           然后用gdb查看：

                # gdb /home/arc/build/linux-2.6/vmlinux
                (gdb) b *0xc10e53d6
                Breakpoint 1 at 0xc10e53d6: file /usr/src/linux-2.6.24-rc3/lib/list_debug.c, line 64.

           看，gdb直接就告訴你在哪個(gè)文件、哪一行了。

           gdb中還可以這樣：

                # gdb Sources/linux-2.6.24/vmlinux
                (gdb) l *do_fork+0x1f
                0xc102b7ac is in do_fork (kernel/fork.c:1385).
                1380
                1381    static int fork_traceflag(unsigned clone_flags)
                1382    {
                1383            if (clone_flags & CLONE_UNTRACED)
                1384                    return 0;
                1385            else if (clone_flags & CLONE_VFORK) {
                1386                    if (current->ptrace & PT_TRACE_VFORK)
                1387                            return PTRACE_EVENT_VFORK;
                1388            } else if ((clone_flags & CSIGNAL) != SIGCHLD) {
                1389                    if (current->ptrace & PT_TRACE_CLONE)
                (gdb)

            也可以直接知道line number。

            或者：

                (gdb) l *(0xffffffff8023eaf0 + 0xff)  /* 出錯(cuò)函數(shù)的地址加上偏移 */



        2, 沒有自己編譯的vmlinux： TIPS

           如果在lkml或bugzilla上看到一個(gè)Oops，而自己不能重現(xiàn)，那就只能反匯編以"Code:"開始的行。 這樣可以嘗試定位到
           源代碼中。

           注意，Oops中的Code:行，會(huì)把導(dǎo)致Oops的第一條指令，也就是EIP的值的第一個(gè)字節(jié)， 用尖括號(hào)<>括起來。 但是，有些
           體系結(jié)構(gòu)(例如常見的x86)指令是不等長(zhǎng)的(不一樣的指令可能有不一樣的長(zhǎng)度)，所以要不斷的嘗試(trial-and-error)。

           Linus通常使用一個(gè)小程序，類似這樣：

                const char array[] = "\xnn\xnn\xnn...";
                int main(int argc, char *argv[])
                {
                        printf("%p\n", array);
                        *(int *)0 = 0;
                }

e.g. /*{{{*/ /* 注意， array一共有從array[0]到array[64]這65個(gè)元素， 其中出錯(cuò)的那個(gè)操作碼<8b> == arry[43] */
#include <stdio.h>
#include <stdlib.h>


const char array[] ="\x6b\xc0\xe8\x2e\x7e\xf6\xff\xe8\xd1\x16\xf2\xff\xb8\x01\x00\x00\x00\xe8\xaa\x1c\xf4\xff\x89\xd8\x83\xc4\x10\x5b\x5d\xc3\x90\x90\x90\x55\x89\xe5\x53\x83\xec\x0c\x8b\x48\x04\x8b\x11\x39\xc2\x74\x18\x89\x54\x24\x08\x89\x44\x24\x04\xc7\x04\x24\xbe\x32\x6b\xc0";
int main(int argc, char *argv[])
{
        printf("%p\n", array);
        *(int *)0 = 0;
}
/*}}}*/



           用gcc -g編譯，在gdb里運(yùn)行它：

                [arc@dhcp-cbjs05-218-251 ~]$ gdb hello
                GNU gdb Fedora (6.8-1.fc9)
                Copyright (C) 2008 Free Software Foundation, Inc.
                License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
                This is free software: you are free to change and redistribute it.
                There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
                and "show warranty" for details.
                This GDB was configured as "x86_64-redhat-linux-gnu"...
                (no debugging symbols found)
                (gdb) r
                Starting program: /home/arc/hello
                0x80484e0

                Program received signal SIGSEGV, Segmentation fault.

           注意，這時(shí)候就可以反匯編0x80484e0這個(gè)地址：

                (gdb) disassemble 0x80484e0
                Dump of assembler code for function array:
                0x080484e0 <array+0>:   imul   $0xffffffe8,%eax,%eax
                0x080484e3 <array+3>:   jle,pn 0x80484dc <__dso_handle+20>
                0x080484e6 <array+6>:   ljmp   *<internal disassembler error>
                0x080484e8 <array+8>:   rcll   (%esi)
                0x080484ea <array+10>:  repnz (bad)
                0x080484ec <array+12>:  mov    $0x1,%eax
                0x080484f1 <array+17>:  call   0x7f8a1a0
                0x080484f6 <array+22>:  mov    %ebx,%eax
                0x080484f8 <array+24>:  add    $0x10,%esp
                0x080484fb <array+27>:  pop    %ebx
                0x080484fc <array+28>:  pop    %ebp
                0x080484fd <array+29>:  ret
                0x080484fe <array+30>:  nop
                0x080484ff <array+31>:  nop
                0x08048500 <array+32>:  nop
                0x08048501 <array+33>:  push   %ebp
                0x08048502 <array+34>:  mov    %esp,%ebp
                0x08048504 <array+36>:  push   %ebx
                0x08048505 <array+37>:  sub    $0xc,%esp
                0x08048508 <array+40>:  mov    0x4(%eax),%ecx
                0x0804850b <array+43>:  mov    (%ecx),%edx
                0x0804850d <array+45>:  cmp    %eax,%edx
                0x0804850f <array+47>:  je     0x8048529
                0x08048511 <array+49>:  mov    %edx,0x8(%esp)
                0x08048515 <array+53>:  mov    %eax,0x4(%esp)
                0x08048519 <array+57>:  movl   $0xc06b32be,(%esp)
                0x08048520 <array+64>:  add    %ah,0xa70
                End of assembler dump.
                (gdb)

          OK, 現(xiàn)在你知道出錯(cuò)的那條指令是array[43]，也就是mov    (%ecx),%edx，也就是說，(%ecx)指向了一個(gè)錯(cuò)誤內(nèi)存地址。

補(bǔ)充：

為了使匯編代碼和C代碼更好的對(duì)應(yīng)起來， Linux內(nèi)核的Kbuild子系統(tǒng)提供了這樣一個(gè)功能： 任何一個(gè)C文件都可以單獨(dú)編譯成匯編文件，例如：

make path/to/the/sourcefile.s

例如我想把kernel/sched.c編譯成匯編，那么：

make kernel/sched.s V=1

或者：

make kernel/sched.lst V=1

         編譯出*.s文件
           
           有時(shí)侯需要對(duì)*.s文件進(jìn)行分析，以確定BUG所在的位置。 對(duì)任何一個(gè)內(nèi)核build目錄下的*.c文件，都可以
           直接編譯出*.s文件。

                   # make drivers/net/e100.s V=1
           
           而對(duì)于自己寫的module，就需要在Makefile中有一個(gè)靈活的target寫法：
                  
                # cat Makefile
                obj-m := usb-skel.o
                KDIR := /lib/modules/`uname -r`/build
                traget := modules

                default:
                        make -C $(KDIR) M=$(shell pwd) $(target)
                clean:
                        rm -f *.o *.ko .*.cmd *.symvers *.mod.c
                        rm -rf .tmp_versions


                # make target=usb-skel.s V=1
           
           這樣，kbuild系統(tǒng)才知道你要make的目標(biāo)不是modules，而是usb-skel.s。




另外， 內(nèi)核源代碼目錄的./scripts/decodecode文件是用來解碼Oops的：

./scripts/decodecode < Oops.txt

(我沒用過，就只提一下。)

不錯(cuò)，以前調(diào)試都是亂摸索

albcamus

原帖由 zx_wing 于 2008-6-5 14:09 發(fā)表
如果有個(gè)自動(dòng)objdump的功能就好了，因?yàn)榫幾g生成的.s文件都沒連接，好多地址都沒替換，有時(shí)候不好用

你要的是不是：

make kernel/sched.lst

？

wifi

好貼，留個(gè)影先，慢慢看。

cyq526

通過死機(jī)位置和棧信息查找死機(jī)所在模塊
RIP: 0010:[<ffffffff8016e5a9>] <ffffffff8016e5a9>{free_block+233}
Call Trace:
<IRQ><ffffffff8016e0ba>{cache_flusharray+138}
       <ffffffff8016e2c7>{kmem_cache_free+55}
       <ffffffff80168b14>{mempool_free+100}
       <ffffffff80192dc4>{bio_destructor+52}
       <ffffffff80192d79>{bio_put+57}
       <ffffffff8018f18a>{end_bio_bh_io_sync+58}
       <ffffffff80192e3d>{bio_endio+93}
       <ffffffff802858d6>{__end_that_request_first+550}
       <ffffffffa0006271>{:scsi_mod:scsi_end_request+129}
       <ffffffffa00065ee>{:scsi_mod:scsi_io_completion+670}
       <ffffffffa0000496>{:scsi_mod:scsi_finish_command+214}
       <ffffffffa0000e3a>{:scsi_mod:scsi_softirq+234}
       <ffffffff80142a23>{__do_softirq+83}
       <ffffffff80142ab5>{do_softirq+53}
       <ffffffff80113d2d>{do_IRQ+317}
       <ffffffff80110c0d>{ret_from_intr+0}  
<EOI>
Code: 48 89 50 08 48 89 02 48 2b 7e 18 48 c7 06 00 01 10 00 48 c7




如何反匯編及定位死機(jī)所在代碼
    #objdump -DSslt vmlinux > kernel-2.6.9-55.S
ffffffff8016e58f:        00
ffffffff8016e590:        48 29 d0                     sub    %rdx,%rax
ffffffff8016e593:        48 c1 e0 03                  shl    $0x3,%rax
ffffffff8016e597:        48 03 81 e0 cc 00 00         add    0xcce0(%rcx),%rax
ffffffff8016e59e:        48 8b 70 20                  mov    0x20(%rax),%rsi
ffffffff8016e5a2:        48 8b 56 08                  mov    0x8(%rsi),%rdx
ffffffff8016e5a6:        48 8b 06                     mov    (%rsi),%rax
ffffffff8016e5a9:        48 89 50 08                  mov    %rdx,0x8(%rax)
ffffffff8016e5ad:        48 89 02                     mov    %rax,(%rdx)
ffffffff8016e5b0:        48 2b 7e 18                  sub    0x18(%rsi),%rdi
ffffffff8016e5b4:        48 c7 06 00 01 10 00         movq   $0x100100,(%rsi)
ffffffff8016e5bb:        48 c7 46 08 00 02 20         movq   $0x200200,0x8(%rsi)
ffffffff8016e5c2:        00


static inline void __list_del(struct list_head * prev, struct list_head * next)
{
ffffffff80152b1c:        48 8b 56 08                  mov    0x8(%rsi),%rdx
ffffffff80152b20:        48 8b 06                     mov    (%rsi),%rax
include/linux/list.h:151
        next->prev = prev;
ffffffff80152b23:        48 89 50 08                  mov    %rdx,0x8(%rax)
include/linux/list.h:152
        prev->next = next;
ffffffff80152b27:        48 89 02                     mov    %rax,(%rdx)
mm/slab.c:2160
ffffffff80152b2a:        48 2b 4e 18                  sub    0x18(%rsi),%rcx


反匯編出來的代碼沒有對(duì)應(yīng)的源碼怎么辦？

修改Makefile或export CONFIG_DEBUG_INFO=1
ifdef CONFIG_DEBUG_INFO
CFLAGS          += -g
endif

# Use LINUXINCLUDE when you must reference the include/ directory.
# Needed to be compatible with the O= option
LINUXINCLUDE    := -Iinclude \
                   $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include)

CPPFLAGS        := -D__KERNEL__ $(LINUXINCLUDE)

CFLAGS          := -Wall -Wstrict-prototypes -Wno-trigraphs \
                   -fno-strict-aliasing -fno-common
AFLAGS          := -D__ASSEMBLY__



死機(jī)信息分析
Oops: 0002 [1] SMP
CPU 2
Pid: 22827, comm: stress Tainted: GF  U   (2.6.5-7.244-smp SLES9_SP3_BRANCH-200512121832250000)
RIP: 0010:[<ffffffff8016e5ad>] <ffffffff8016e5ad>{free_block+237}

Oops：表示當(dāng)前內(nèi)核故障類型
002：頁面錯(cuò)誤碼，表示內(nèi)核試圖寫一個(gè)不存在的頁面
[1]：死機(jī)計(jì)數(shù)器，記錄冊(cè)從上次系統(tǒng)重啟以來的死機(jī)次數(shù)
CPU：表示系統(tǒng)運(yùn)行故障時(shí)所在的CPU
Pid：系統(tǒng)故障時(shí)，運(yùn)行的進(jìn)程
RIP：系統(tǒng)故障時(shí)，執(zhí)行的指令位置
Tainted:表示內(nèi)核被一些模塊污染
寄存器和棧信息對(duì)深入分析故障原因有一定幫助。

通過出錯(cuò)打印信息，在內(nèi)核源碼中查找出錯(cuò)位置
     這種情況下為沒有出錯(cuò)棧信息時(shí)用，多為非死機(jī)時(shí)內(nèi)核打印出的故障信息，如文件系統(tǒng)只讀、殺死進(jìn)程。

Aborting journal on device mtdblock51.
EXT3-fs error (device mtdblock51) in ext3_reserve_inode_write: Journal has aborted
EXT3-fs error (device mtdblock51) in ext3_truncate: Journal has aborted
EXT3-fs error (device mtdblock51) in ext3_delete_inode: IO failure
EXT3-fs error (device mtdblock51) in ext3_reserve_inode_write: Journal has aborted
EXT3-fs error (device mtdblock51) in ext3_orphan_del: Journal has aborted
EXT3-fs error (device mtdblock51) in ext3_reserve_inode_write: Journal has aborted
EXT3-fs error (device mtdblock51) in ext3_delete_inode: Journal has aborted
ext3_abort called.
EXT3-fs error (device mtdblock51): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_committed_data

satfire

mark..
好帖.

Godbach

請(qǐng)教版主一個(gè)問題，如果是我自己寫的內(nèi)核模塊程序，他的oops信息該如何解析。
OOPS最后一行的，EIP is at ********按照本帖提供的方法，該如何查找模塊的BUG所在呢

[ 本帖最后由 Godbach 于 2008-10-29 11:56 編輯 ]

albcamus

$ grep sd_mod /proc/modules
sd_mod 29504 11 - Live 0xffffffffa007c000
scsi_mod 163000 5 usb_storage,sr_mod,sg,libata,sd_mod, Live 0xffffffffa0053000

(gdb) add-symbol-files  <path to your sd_mod.ko>  0xffffffffa007c000

Godbach

原帖由 albcamus 于 2008-10-29 12:28 發(fā)表
$ grep sd_mod /proc/modules
sd_mod 29504 11 - Live 0xffffffffa007c000
scsi_mod 163000 5 usb_storage,sr_mod,sg,libata,sd_mod, Live 0xffffffffa0053000

(gdb) add-symbol-files    0xffffffffa007c000

多謝斑竹指點(diǎn)。

(gdb) add-symbol-files    0xffffffffa007c000

這一行沒搞清楚怎么用。