zoukankan      html  css  js  c++  java

  • Oops信息及栈回溯

    1. Oops信息来源及格式
    Oops这个单词含义为“惊讶”，当内核出错时（比如访问非法地址）打印出来的信息被称为Oops信息。
    Oops信息包含以下几部分内容：
    （1）一段文本描述信息。
          比如类似“Unable to handle kernel NULL pointer dereference at virtual address 00000000"的信息，他说明了发生的是哪类错误。
    （2）Oops信息的序号。
          比如是第几次等。这些信息与下面类似，括号内的数据表示序号。

    1. Internal error: Oops: 806 [#1]

    （3）内核中加载的模块名称，也可能没有，以下面字样开头。

    1. Modules linked in:

    （4）发生错误的CPU的序号，对于单处理器系统，序号为0，如：

    1. CPU: 0 Not tainted (2.6.22.6 #36)

    （5）发生错误时CPU的各个寄存器值。
    （6）当前进程的名字及进程ID，比如：

    1. Process swapper (pid: 1, stack limit = 0xc0480258)

    这并不是说发生错误的是这个进程，而是表示发生错误时，当前进程是它。错误可能发生在内核代码、驱动程序，也可能就是这个进程的错误。
    （7）栈信息。
    （8）栈回溯信息，可以从中看出函数调用关系，形式如下：

    1. Backtrace:
    2. [<c001a6f4>] (s3c2410fb_probe+0x0/0x560) from [<c01bf4e8>] (platform_drv_probe+0x20/0x24)
    3. ......

    （9）出错指令附近的指令机器码，比如（出错指令在小括号内）：

    1. Code: e24cb004 e24dd010 e59f34e0 e3a07000 (e5873000)

    2. 配置内核使Oops信息的栈回溯信息更直观
    Linux 2.26.32自身具备的调试功能，可以使打印出的Oops信息更直观。通过Oops信息中PC寄存器的值可以知道出错指令的地址，通过栈回溯信息可以知道出错时的函数调用关系，根据这两点可以很快定位错误。
    要让内核出错时能够打印栈回溯信息，编译内核时要增加“-fno-omit-frame-pointer"选项，这可以通过配置CONFIG_FRAME_POINTER来实现。查看内核目录下的配置文件.config，确保    CONFIG_FRAME_POINTER已经被定义，如果没有，执行“make menuconfig”命令重新配置内核。CONFIG_FRAME_POINTER有可能被其他配置项目自动选上。

    3使用Oops信息调试内核的实例
    （1）获得Oops信息
    本小节故意修改 LCD 驱动程序 drivers/video/s3c2410fb.c,加入错误代码:在 s3c2410fb_
    probe 函数的开头增加下面两条代码:

    1. int *ptest = NULL;
    2. *ptest = 0x1234;

    重新编译内核,启动后会出错并打印出如下 Oops 信息:

    1. Unable to handle kernel NULL pointer dereference at virtual address 00000000
    2. pgd = c0004000
    3. [00000000] *pgd=00000000
    4. Internal error: Oops: 805 [#1]
    5. last sysfs file:
    6. Modules linked in:
    7. CPU: 0 Not tainted (2.6.32 #24)
    8. PC is at s3c2410fb_probe+0xc/0x18
    9. LR is at platform_drv_probe+0x18/0x1c
    10. pc : [<c0018f78>] lr : [<c01d3f88>] psr: a0000013
    11. sp : c3823f30 ip : c3842e7c fp : 00000000
    12. r10: 00000000 r9 : 00000000 r8 : c0445008
    13. r7 : c38a0840 r6 : c0440d18 r5 : c042d178 r4 : 00000000
    14. r3 : 00001234 r2 : 00000000 r1 : 00000000 r0 : c042d170
    15. Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
    16. Control: c000717f Table: 30004000 DAC: 00000017
    17. Process swapper (pid: 1, stack limit = 0xc3822270)
    18. Stack: (0xc3823f30 to 0xc3824000)
    19. 3f20: 00000000 c01d2e7c c0440d18 c042d178
    20. 3f40: 0000000c c042d178 c042d1ac c0440d18 c38a0840 c01d3068 00000000 c01d300c
    21. 3f60: c0440d18 c01d24e8 c3804938 c3847330 00000000 00000000 c0440d18 c01d1d48
    22. 3f80: c03a1506 c03a1506 00000001 c0022dd4 00000000 c0440d18 c0018f84 00000000
    23. 3fa0: 00000000 c01d3334 c0022dd4 00000000 00000000 c0018f84 00000000 c0018f90
    24. 3fc0: c0022dd4 c002e37c c0018f84 c03c5ab3 c0457880 c0022fc8 c0022dd4 00000000
    25. 3fe0: 00000000 00000000 00000000 c00083f8 00000000 c002fe54 00000000 00000000
    26. [<c0018f78>] (s3c2410fb_probe+0xc/0x18) from [<c01d3f88>] (platform_drv_probe+0x18/0x1c)
    27. [<c01d3f88>] (platform_drv_probe+0x18/0x1c) from [<c01d2e7c>] (driver_probe_device+0x148/0x2d8)
    28. [<c01d2e7c>] (driver_probe_device+0x148/0x2d8) from [<c01d3068>] (__driver_attach+0x5c/0x7c)
    29. [<c01d3068>] (__driver_attach+0x5c/0x7c) from [<c01d24e8>] (bus_for_each_dev+0x48/0x78)
    30. [<c01d24e8>] (bus_for_each_dev+0x48/0x78) from [<c01d1d48>] (bus_add_driver+0xe0/0x288)
    31. [<c01d1d48>] (bus_add_driver+0xe0/0x288) from [<c01d3334>] (driver_register+0xa4/0x130)
    32. [<c01d3334>] (driver_register+0xa4/0x130) from [<c0018f90>] (s3c2410fb_init+0xc/0x28)
    33. [<c0018f90>] (s3c2410fb_init+0xc/0x28) from [<c002e37c>] (do_one_initcall+0x5c/0x1b4)
    34. [<c002e37c>] (do_one_initcall+0x5c/0x1b4) from [<c00083f8>] (kernel_init+0x94/0x10c)
    35. [<c00083f8>] (kernel_init+0x94/0x10c) from [<c002fe54>] (kernel_thread_exit+0x0/0x8)
    36. Code: eafffe97 e3a02000 e59f3008 e1a01002 (e5823000)
    37. ---[ end trace da227214a82491b7 ]---
    38. swapper used greatest stack depth: 5792 bytes left
    39. Kernel panic - not syncing: Attempted to kill
    40. [<c00352ac>] (unwind_backtrace+0x0/0x150) from [<c0311c54>] (panic+0x40/0x120)
    41. [<c0311c54>] (panic+0x40/0x120) from [<c0046cbc>] (do_exit+0x64/0x5f4)
    42. [<c0046cbc>] (do_exit+0x64/0x5f4) from [<c0032f28>] (die+0x15c/0x180)
    43. [<c0032f28>] (die+0x15c/0x180) from [<c00360a0>] (__do_kernel_fault+0x64/0x74)
    44. [<c00360a0>] (__do_kernel_fault+0x64/0x74) from [<c0036268>] (do_page_fault+0x1b8/0x1cc)
    45. [<c0036268>] (do_page_fault+0x1b8/0x1cc) from [<c002e2c0>] (do_DataAbort+0x34/0x94)
    46. [<c002e2c0>] (do_DataAbort+0x34/0x94) from [<c002ea20>] (__dabt_svc+0x40/0x60)
    47. Exception stack(0xc3823ee8 to 0xc3823f30)
    48. 3ee0: c042d170 00000000 00000000 00001234 00000000 c042d178
    49. 3f00: c0440d18 c38a0840 c0445008 00000000 00000000 00000000 c3842e7c c3823f30
    50. 3f20: c01d3f88 c0018f78 a0000013 ffffffff
    51. [<c002ea20>] (__dabt_svc+0x40/0x60) from [<c0018f78>] (s3c2410fb_probe+0xc/0x18)
    52. [<c0018f78>] (s3c2410fb_probe+0xc/0x18) from [<c01d3f88>] (platform_drv_probe+0x18/0x1c)
    53. [<c01d3f88>] (platform_drv_probe+0x18/0x1c) from [<c01d2e7c>] (driver_probe_device+0x148/0x2d8)
    54. [<c01d2e7c>] (driver_probe_device+0x148/0x2d8) from [<c01d3068>] (__driver_attach+0x5c/0x7c)
    55. [<c01d3068>] (__driver_attach+0x5c/0x7c) from [<c01d24e8>] (bus_for_each_dev+0x48/0x78)
    56. [<c01d24e8>] (bus_for_each_dev+0x48/0x78) from [<c01d1d48>] (bus_add_driver+0xe0/0x288)
    57. [<c01d1d48>] (bus_add_driver+0xe0/0x288) from [<c01d3334>] (driver_register+0xa4/0x130)
    58. [<c01d3334>] (driver_register+0xa4/0x130) from [<c0018f90>] (s3c2410fb_init+0xc/0x28)
    59. [<c0018f90>] (s3c2410fb_init+0xc/0x28) from [<c002e37c>] (do_one_initcall+0x5c/0x1b4)
    60. [<c002e37c>] (do_one_initcall+0x5c/0x1b4) from [<c00083f8>] (kernel_init+0x94/0x10c)
    61. [<c00083f8>] (kernel_init+0x94/0x10c) from [<c002fe54>] (kernel_thread_exit+0x0/0x8)

    （2）分析 Oops 信息

    • 确出错原因。

    由出错信息“Unable to handle kernel NULL pointer dereference at virtual address 00000000”可知内核是因为非法地址访问出错,使用了空指针。

    • 根据栈回溯信息找出函数调用关系。

    内核崩溃时,可以从 pc 寄存器得知崩溃发生时的函数、出错指令。但是很多情况下,错误有可能是它的调用者引入的,所以找出函数的调用关系也很重要。
    部分栈回溯信息如下:

    1. [<c0018f78>] (s3c2410fb_probe+0xc/0x18) from [<c01d3f88>] (platform_drv_probe+0x18/0x1c)

    这行信息分为两部分,表示后面的 platform_drv_probe 函数调用了前面的 s3c2410fb_probe函数。
    前半部含义为:“c0018f78”是 s3c2410fb_probe 函数首地址偏移 0xc 的地址,这个函数大小为 0x18。
    后半部含义为:“c01d3f88”是 platform_drv_probe 函数首地址偏移 0x18 的地址,这个函数大小为 0x1c。
    另外,后半部的“[<c01d3f88>]”表示 s3c2410fb_probe 执行后的返回地址。
    对于类似下面的栈回溯信息,其中是 r8~r4 表示 driver_probe_device 函数刚被调用时这
    些寄存器的值。
    从上面的栈回溯信息可以知道内核出错时的函数调用关系如下,最后在 s3c2410fb_probe函数内部崩溃。

    1. do_exit ->
    2.        kernel_init ->
    3.               do_one_initcall ->
    4.                      s3c2410fb_init ->
    5.                             driver_register ->
    6.                                    bus_add_driver ->
    7.                                           bus_for_each_dev ->
    8.                                                  __driver_attach ->
    9.                                                         driver_probe_device ->
    10.                                                                platform_drv_probe ->
    11.                                                                        s3c2410fb_probe
    • 根据 pc 寄存器的值确定出错位置。

    上述 Oops 信息中出错时的寄存器值如下:

    1. PC is at s3c2410fb_probe+0xc/0x18
    2. LR is at platform_drv_probe+0x18/0x1c
    3. pc : [<c0018f78>] lr : [<c01d3f88>] psr: a0000013
    4. sp : c3823f30 ip : c3842e7c fp : 00000000
    5. r10: 00000000 r9 : 00000000 r8 : c0445008
    6. r7 : c38a0840 r6 : c0440d18 r5 : c042d178 r4 : 00000000
    7. r3 : 00001234 r2 : 00000000 r1 : 00000000 r0 : c042d170

    "PC is at s3c2410fb_probe+0xc/0x18"表示出错指令为 s3c2410fb_probe 函数中偏移为0xc 的指令。
    "pc : [<c0018f78>] "表示出错指令的地址为 c0018f78(十六进制)。

    • 结合内核源代码和反汇编代码定位问题。

    先生成内核的反汇编代码 vmlinux.dis,执行以下命令:

    1. $ cd ~/Documents/myTest/kernel/linux-2.6.32
    2. $ arm-linux-objdump -D vmlinux > vmlinux.dis

    出错地址 c0018f78 附近的部分汇编代码如下:

    1. c0018f64 <s3c2412fb_probe>:
    2. c0018f64: e3a01001 mov r1, #1 ; 0x1
    3. c0018f68: eafffe97 b c00189cc <s3c24xxfb_probe>
    5. c0018f6c <s3c2410fb_probe>:
    6. c0018f6c: e3a02000 mov r2, #0 ; 0x0
    7. c0018f70: e59f3008 ldr r3, [pc, #8] ; c0018f80 <s3c2410fb_probe+0x14>
    8. c0018f74: e1a01002 mov r1, r2
    9. c0018f78: e5823000 str r3, [r2]         <===========出错指令
    10. c0018f7c: eafffe92 b c00189cc <s3c24xxfb_probe>
    11. c0018f80: 00001234 .word 0x00001234
    13. c0018f84 <s3c2410fb_init>:
    14. c0018f84: e92d4010 push {r4, lr}
    15. c0018f88: e59f0014 ldr r0, [pc, #20] ; c0018fa4 <s3c2410fb_init+0x20>
    16. c0018f8c: eb06ed06 bl c01d43ac <platform_driver_register>
    17. c0018f90: e3500000 cmp r0, #0 ; 0x0
    18. c0018f94: 18bd8010 popne {r4, pc}
    19. c0018f98: e59f0008 ldr r0, [pc, #8] ; c0018fa8 <s3c2410fb_init+0x24>
    20. c0018f9c: e8bd4010 pop {r4, lr}
    21. c0018fa0: ea06ed01 b c01d43ac <platform_driver_register>
    22. c0018fa4: c0440d04 .word 0xc0440d04

    出错指令为“str r3, [r2]”,它把 r3 寄存器的值放到内存中,内存地址为 r2 寄存器的值。
    根据 Oops 信息中的寄存器值可知:r3 为     00001234, r2 为 0。0 地址不可访问,所以出错。

    1. static int __init s3c2410fb_probe(struct platform_device *pdev)
    2. {
    3.     // add for kernel panic --begin
    4.     int *ptest = NULL;
    5.     *ptest = 0x1234;
    6.     // add for kernel panic --end
    7.     return s3c24xxfb_probe(pdev, DRV_S3C2410);
    8. }

    结合反汇编代码,很容易知道是“*ptest = 0x1234;”导致错误,其中的 ptest 为空。对于大多数情况,从反汇编代码定位到 C 代码并不会如此容易,这需要较强的阅读汇编程序的能力。通过栈回溯信息知道函数的调用关系,这已经可以帮助定位很多问题了。

    4.使用 Oops 的栈信息手工进行栈回溯
      前面说过,从 Oops 信息的 pc 寄存器值可知得知崩溃发生时的函数、出错指令。但是错误有可能是它的调用者引入的,所以还要找出函数的调用关系。由于内核配置了 CONFIG_FRAME_POINTER,当出现 Oops 信息时,会打印栈回溯信息。如果内核没有配置 CONFIG_FRAME_POINTER,这时可以自己分析栈信息,找到函数的调用关系。
     (1)栈的作用
    一个程序包含代码段、数据 段、BSS 段、堆、栈;其中数据段用来中存储初始值不为 0 的全局数据,BSS 段用来存储初始值为 0 的全局数据,堆用于动态内存分配,栈用于实现函数调用、存储局部变量。被调用函数在执行之前,它会将一些寄存器的值保存在栈中,其中包括返回地址寄存器 lr。如果知道了所保存的 lr 寄存的值,那么就可以知道它的调用者是谁。在栈信息中,一个函数一个函数地往上找出所有保存的 lr 值,就可以知道各个调用函数,这就是栈回溯的原理。
     (2)栈回溯实例分析
    仍以前面的 LCD 驱动程序为例,使用上面的 Oops 信息的栈信息进行分析,栈信息如下:

    1. Stack: (0xc3823f30 to 0xc3824000)
    2. 3f20: 00000000 c01d2e7c c0440d18 c042d178
    3. 3f40: 0000000c c042d178 c042d1ac c0440d18 c38a0840 c01d3068 00000000 c01d300c
    4. 3f60: c0440d18 c01d24e8 c3804938 c3847330 00000000 00000000 c0440d18 c01d1d48
    5. 3f80: c03a1506 c03a1506 00000001 c0022dd4 00000000 c0440d18 c0018f84 00000000
    6. 3fa0: 00000000 c01d3334 c0022dd4 00000000 00000000 c0018f84 00000000 c0018f90
    7. 3fc0: c0022dd4 c002e37c c0018f84 c03c5ab3 c0457880 c0022fc8 c0022dd4 00000000
    8. 3fe0: 00000000 00000000 00000000 c00083f8 00000000 c002fe54 00000000 00000000
    • 根据 pc 寄存器值找到第一个函数,确定它的栈大小,确定调用函数。

    从 Oops 信息

    1. PC is at s3c2410fb_probe+0xc/0x18
    2.     LR is at platform_drv_probe+0x18/0x1c
    3.     pc : [<c0018f78>] lr : [<c01d3f88>] psr: a0000013
    4.     sp : c3823f30 ip : c3842e7c fp : 00000000
    5.     r10: 00000000 r9 : 00000000 r8 : c0445008
    6.     r7 : c38a0840 r6 : c0440d18 r5 : c042d178 r4 : 00000000
    7.     r3 : 00001234 r2 : 00000000 r1 : 00000000 r0 : c042d170

    可知 pc 值为 c0018f78,使用它在内核反汇编程序 vmlinux.dis 中可以知道它位于 s3c2410fb_probe 函数内。

    1. c0018f6c <s3c2410fb_probe>:
    2. c0018f6c: e3a02000 mov r2, #0 ; 0x0
    3. c0018f70: e59f3008 ldr r3, [pc, #8] ; c0018f80 <s3c2410fb_probe+0x14>
    4. c0018f74: e1a01002 mov r1, r2
    5. c0018f78: e5823000 str r3, [r2] <===========出错指令
    6. c0018f7c: eafffe92 b c00189cc <s3c24xxfb_probe>
    7. c0018f80: 00001234 .word 0x00001234

    lr存放的是函数返回值地址，为c01d3f88，根据这个地址，搜索内核反汇编程序 vmlinux.dis ，可知它位于：

    1. c01d3f70 <platform_drv_probe>:
    2. c01d3f70: e92d4010 push {r4, lr}
    3. c01d3f74: e1a03000 mov r3, r0
    4. c01d3f78: e5933044 ldr r3, [r3, #68]
    5. c01d3f7c: e2400008 sub r0, r0, #8 ; 0x8
    6. c01d3f80: e1a0e00f mov lr, pc
    7. c01d3f84: e513f014 ldr pc, [r3, #-20]
    8. c01d3f88: e8bd8010 pop {r4, pc}

    也就是说，函数s3c2410fb_probe() 被platform_drv_probe()调用。再看platform_drv_probe()的反汇编代码，期中

    1. c01d3f70: e92d4010 push {r4, lr}

    栈中存放的是 r4, lr
    对应

    1. Stack: (0xc3823f30 to 0xc3824000)
    2. 3f20:                                                                            00000000 c01d2e7c c0440d18 c042d178
    3. 3f40: 0000000c c042d178 c042d1ac c0440d18 c38a0840 c01d3068 00000000 c01d300c
    4. 3f60: c0440d18 c01d24e8 c3804938 c3847330 00000000 00000000 c0440d18 c01d1d48
    5. 3f80: c03a1506 c03a1506 00000001 c0022dd4 00000000 c0440d18 c0018f84 00000000
    6. 3fa0: 00000000 c01d3334 c0022dd4 00000000 00000000 c0018f84 00000000 c0018f90
    7. 3fc0: c0022dd4 c002e37c c0018f84 c03c5ab3 c0457880 c0022fc8 c0022dd4 00000000
    8. 3fe0: 00000000 00000000 00000000 c00083f8 00000000 c002fe54 00000000 00000000

    其中，lr对应的值为c01d2e7c，用此值检索vmlinux.dis，位于

    1. c01d2d34 <driver_probe_device>:
    2. c01d2d34: e92d40f7 push {r0, r1, r2, r4, r5, r6, r7, lr}
    3. c01d2d38: e5d13028 ldrb r3, [r1, #40]
    4. c01d2d3c: e1a05001 mov r5, r1
    5. ....
    6. c01d2e7c: e2504000 subs r4, r0, #0 ; 0x0
    7. c01d2e80: 1a000016 bne c01d2ee0 <driver_probe_device+0x1ac>
    8. c01d2e84: e1a00005 mov r0, r5
    9. c01d2e88: ebffff6e bl c01d2c48 <driver_bound>

    可知，platform_drv_probe()被driver_probe_device()调用，再用同样的方法就可以找出所有函数调用关系。

    附：

    arm-none-eabi-objdump -Dz -S vmlinux >linux.dump

    值得注意的是，arm-none-eabi-objdump的参数-S表示尽可能的把原来的代码和反汇编出来的代码一起呈现出来，-S参数需要结合 arm-linux-gcc编译参数-g，才能达到反汇编时同时输出原来的代码。所以，我在linux内核代码根目录的Makefile中增加-g编译参 数：

    KBUILD_CFLAGS   := -g -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
         -fno-strict-aliasing -fno-common
         -Werror-implicit-function-declaration
         -Wno-format-security
         -fno-delete-null-pointer-checks

    修改Makefile后，重新编译内核，在根目录中生成的vmlinux文件就会包含了原来的代码信息，这时再执行arm-none-eabi-objdump -Dz -S vmlinux >linux.dump需要数个小时的时间。
  • 相关阅读:
    个性化离线实时分析系统pora
    关于android上的定位
    Enthought Python Distribution :: Products :: Enthought, Inc.
    刘思喆@贝吉塔行星
    Bio and Geo Informatics: kmeans clustering in scipy
    RDataMining.com: R and Data Mining
    First steps in text mining with R
    “逻辑回归” 和 "线性回归" 的关系
    crontab 每月执行一次怎么写？ Linux系统管理 ChinaUnix.net
    RDataMining.com: R and Data Mining
  • 原文地址：https://www.cnblogs.com/watson/p/3779838.html
Copyright © 2011-2022 走看看