gdb 定位 oops call trace

[    1.454380] BUG: unable to handle kernel NULL pointer dereference at 00000000000005d0
[    1.474020] IP: [<ffffffff8144375b>] DSFW_rx_handle+0x1bb/0x370
[    1.487902] PGD 139c25067 PUD 135301067 PMD 0
[    1.497467] Oops: 0000 [#1] SMP
[    1.503342] Modules linked in:
[    1.508646] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.10.52-waf #133
[    1.524811] Hardware name: To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M., BIOS 4.6.4 01/06/2012
[    1.552962] task: ffff88013b0c0ba0 ti: ffff88013b0d4000 task.ti: ffff88013b0d4000
[    1.571471] RIP: 0010:[<ffffffff8144375b>]  [<ffffffff8144375b>] DSFW_rx_handle+0x1bb/0x370
[    1.592629] RSP: 0018:ffff88013b0d5c98  EFLAGS: 00010202
[    1.604640] RAX: 00000000fffffffe RBX: ffff8801353c4d00 RCX: 00000000001978fd
[    1.622107] RDX: 0000000000000043 RSI: ffff88012bb00180 RDI: 00000000000005a8
[    1.639575] RBP: 00000000000005a8 R08: 0000000000016d20 R09: 0000000000000000
[    1.657043] R10: 0000000000000000 R11: ffff88011d1e2e2a R12: 0000000000000001
[    1.674511] R13: 0000000000020063 R14: ffff8801378ea3d0 R15: 000000000000003e
[    1.691981] FS:  0000000000000000(0000) GS:ffff88013fa00000(0000) knlGS:0000000000000000
[    1.712308] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.725618] CR2: 00000000000005d0 CR3: 00000001353c6000 CR4: 00000000000407b0
[    1.743085] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    1.760553] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[    1.778019] Stack:
[    1.780151]  ffff8801378ea3e0 ffffc90001cc3988 ffff8801353c4d00 ffffffff812b87f6
[    1.798609]  ffff88013b008900 ffff880137e87d00 ffff880137edc680 ffff88013b0d5d64
[    1.817064]  ffffc90001cc39b0 0001397200000100 ffff880137edc000 ffffffff814435a0
[    1.835520] Call Trace:
[    1.838954]  [<ffffffff812b87f6>] ? e1000e_clean_rx_irq_nff+0x256/0xbc0
[    1.854861]  [<ffffffff814435a0>] ? DSFW_fif_recv+0x70/0x70
[    1.867650]  [<ffffffff812b91ce>] ? e1000e_poll+0x6e/0x1c0
[    1.880179]  [<ffffffff81389a68>] ? net_rx_action+0x88/0x170
[    1.893228]  [<ffffffff81037f46>] ? __do_softirq+0xd6/0x290
[    1.906015]  [<ffffffff81038129>] ? run_ksoftirqd+0x29/0x40
[    1.918806]  [<ffffffff810591d3>] ? smpboot_thread_fn+0x103/0x190
[    1.933156]  [<ffffffff810590d0>] ? lg_global_unlock+0x60/0x60
[    1.946723]  [<ffffffff81052088>] ? kthread+0xb8/0xc0
[    1.957954]  [<ffffffff81051fd0>] ? __kthread_parkme+0x80/0x80
[    1.971522]  [<ffffffff814e121c>] ? ret_from_fork+0x7c/0xb0
[    1.984311]  [<ffffffff81051fd0>] ? __kthread_parkme+0x80/0x80
[    1.997877] Code: 00 48 98 48 c1 e0 06 01 90 f0 98 9d 81 83 80 f4 98 9d 81 01 48 85 ed 75 0f eb 4d 0f 1f 44 00 00 48 85 db 74 43 48 89 dd 48 89 ef <48> 8b 5d 28 e8 6c fd ff ff 85 c0 74 e8 8b 85 d4 00 00 00 83 f8
[    2.053478] RIP  [<ffffffff8144375b>] DSFW_rx_handle+0x1bb/0x370
[    2.067594]  RSP <ffff88013b0d5c98>
[    2.074145] CR2: 00000000000005d0

例如
[    2.053478] RIP  [<ffffffff8144375b>] DSFW_rx_handle+0x1bb/0x370

ffffffff8144375b 是指令在内存中的虚拟地址
DSFW_rx_handle  是函数(symbol 名)
0x1bb/0x370 ,0x370 是这个函数编译成机器码后的长度,0x1bb是ffffffff8144375b这条指令在相对于
DSFW_rx_handle 函数入口的偏移

gdb定位

# gdb vmlinux
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 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-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/wesley/dvlp/WAF/trunk/build/linux-3.10.52/vmlinux...done.
(gdb) l *DSFW_rx_handle+0x1bb/0x370

时间: 2024-10-29 19:10:00

gdb 定位 oops call trace的相关文章

段错误Segment Fault定位,即core dump文件与gdb定位

使用C++开发系统有时会出现段错误,即Segment Fault.此类错误程序直接崩溃,通常没有任何有用信息输出,很难定位bug,因而无从解决问题.今天我们介绍core dump文件,并使用gdb进行调试,以此来定位段错误问题.此文同时用以备忘. 一.core dump Core dump也称核心转储, 当程序运行过程中异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 称之为core dump文件. 系统默认不生成core dump文件,可以使用ulimit命令进行查看和设

【Z】段错误Segment Fault定位,即core dump文件与gdb定位

使用C++开发系统有时会出现段错误,即Segment Fault.此类错误程序直接崩溃,通常没有任何有用信息输出,很难定位bug,因而无从解决问题.今天我们介绍core dump文件,并使用gdb进行调试,以此来定位段错误问题.此文同时用以备忘. 一.core dump Core dump也称核心转储, 当程序运行过程中异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 称之为core dump文件. 系统默认不生成core dump文件,可以使用ulimit命令进行查看和设

linux设备驱动第四篇:从如何定位oops的代码行谈驱动调试方法

上一篇我们大概聊了如何写一个简单的字符设备驱动,我们不是神,写代码肯定会出现问题,我们需要在编写代码的过程中不断调试.在普通的c应用程序中,我们经常使用printf来输出信息,或者使用gdb来调试程序,那么驱动程序如何调试呢?我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题,在应用程序中运行这种程序就会报segmentation fault的错误,而由于驱动程序的特殊性,出现此类情况后往往会直接造成系统宕机,并会抛出oops信息.那么我们如何来分析oops信息呢,甚至根据oop

oops call trace 解析

Call Trace: [  221.634988]  [<ffffffff8103fbc7>] ? kmld_pte_lookup+0x17/0x60 [  221.635016]  [<ffffffff8103ff04>] ? kmld_fault+0x94/0xf0 [  221.635051]  [<ffffffff8103fbc7>] ? kmld_pte_lookup+0x17/0x60 [  221.635079]  [<ffffffff8103ff

[fw]Understanding a Kernel Oops!

An “Oops” is what the kernel throws at us when it finds something faulty, or an exception, in the kernel code. It’s somewhat like the segfaults of user-space. An Oops dumps its message on the console; it contains the processor status and the CPU regi

GDB core命令的使用调试段错误

#include <stdio.h> void func(){ int *p = NULL; printf("*p:%d\n", *p);//断错误 } int main(void){ func(); return 0; } 1.首先设置开关 设置 core文件的大小为1000K存放数据 [[email protected] clession]$ ulimit -c0[[email protected] clession]$ ulimit -c 1000 2. 编译-g调试

红帽Linux故障定位技术详解与实例(2)

红帽Linux故障定位技术详解与实例(2) 2011-09-28 14:26 圈儿 BEAREYES.COM 我要评论(0) 字号:T | T 在线故障定位就是在故障发生时, 故障所处的操作系统环境仍然可以访问,故障处理人员可通过console, ssh等方式登录到操作系统上,在shell上执行各种操作命令或测试程序的方式对故障环境进行观察,分析,测试,以定位出故障发生的原因. AD:2014WOT全球软件技术峰会北京站 课程视频发布 3.内核故障情形及处理 (1)内核panic panic是内

Linux内核死机调试方法总结

使用空指针和缓冲区溢出是产生oops的两个最常见原因. 1.直接查看oops信息,首先查找源代码发生oops的位置,通过查看指令寄存器EIP的值,可以找到位置.再查找函数调用栈可以得到更多的信息.从函数调用栈可辨别出局部变量,全局变量和函数参数.较为重要的信息就是指令指针(EIP),即出错指令的地址. 例如:在函数faulty_read的oops信息的函数调用栈中,栈顶为ffffffff,栈顶值应为一个小于ffffffff的值,为此值,说明再找不回调用函数地址,说明有可能因缓冲区溢出等原因造成指

Linux Kernel - Debug Guide (Linux内核调试指南 )

http://blog.csdn.net/blizmax6/article/details/6747601 linux内核调试指南 一些前言 作者前言 知识从哪里来 为什么撰写本文档 为什么需要汇编级调试 ***第一部分:基础知识*** 总纲:内核世界的陷阱 源码阅读的陷阱 代码调试的陷阱 原理理解的陷阱 建立调试环境 发行版的选择和安装 安装交叉编译工具 bin工具集的使用 qemu的使用 initrd.img的原理与制作 x86虚拟调试环境的建立 arm虚拟调试环境的建立 arm开发板调试环