oops call trace 解析

最新推荐文章于 2024-01-15 10:12:50 发布
转载 最新推荐文章于 2024-01-15 10:12:50 发布 · 2.4k 阅读 · 2
文章标签：

#call trace

本文详细解析了Linux内核中的Call Trace日志，通过具体实例介绍了如何理解日志中各部分信息，如函数地址、函数名称及指令偏移等，帮助读者掌握内核故障排查技巧。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

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]  [<ffffffff8103ff04>] kmld_fault+0x94/0xf0
[  221.635109]  [<ffffffff815c8f95>] do_page_fault+0x3f5/0x550
[  221.635140]  [<ffffffff8104e36d>] ? set_next_entity+0x9d/0xb0
[  221.635169]  [<ffffffff8104e497>] ? pick_next_task_fair+0xc7/0x110
[  221.635209]  [<ffffffff815c5a95>] page_fault+0x25/0x30
[  221.635245]  [<ffffffff811675c7>] ? copy_strings+0x97/0x240
[  221.635272]  [<ffffffff811675af>] ? copy_strings+0x7f/0x240
[  221.635299]  [<ffffffff81167f92>] do_execve+0x202/0x2b0
[  221.635326]  [<ffffffff81012847>] sys_execve+0x47/0x70
[  221.635360]  [<ffffffff815cd81c>] stub_execve+0x6c/0xc

 

例如[ 221.634988] [<ffffffff8103fbc7>] ? kmld_pte_lookup+0x17/0x60

ffffffff8103fbc7 是指令在内存中的虚拟地址
kmld_pte_lookup  是函数(symbol 名)
0x17/0x60 ，0x60是这个函数编译成机器码后的长度，0x17是ffffffff8103fbc7这条指令在相对于kmld_pte_lookup这个函数入口的偏移


从零开始之驱动发开、linux驱动（六十八、内核调试篇--Oops解析）
To_run_away的博客
05-01 1721
什么是Oops？ 从语言学的角度说，Oops应该是一个拟声词。当出了点小事故，或者做了比较尴尬的事之后，你可以说"Oops"，翻译成中国话就叫做“哎呦”。“哎呦，对不起，对不起，我真不是故意打碎您的杯子的”。看，Oops就是这个意思。 在Linux内核开发中的Oops是什么呢？其实，它和上面的解释也没什么本质的差别，只不过说话的主角变成了Linux。当某些比较致命的问题出现时，我们的Linux...
RK3568平台（调试篇）内核OOPS信息解读
weixin_49303682的博客
09-17 235
什么是Oops？从语言学的角度说，Oops应该是一个拟声词。当出了点小事故，或者做了比较尴尬的事之后，你可以说"Oops"，翻译成中国话就叫做“哎呦”。“哎呦，对不起，对不起，我真不是故意打碎您的杯子的”。看，Oops就是这个意思。在Linux内核开发中的Oops是什么呢？其实，它和上面的解释也没什么本质的差别，只不过说话的主角变成了Linux。当某些比较致命的问题出现时，我们的Linux内核也会抱歉的对我们说：“哎呦(Oops)，对不起，我把事情搞砸了”。
Linux Call Trace原理分析
热门推荐
walkingman321的专栏
01-03 5万+
本文介绍了在Linux环境下根据EABI标准进行call dump调试的一般性原理。Linux开发过程中，由于程序不稳定，经常会出现错误，导致程序异常，甚至崩溃。这时，就需要有一种机制将崩溃时的函数调用栈打印出来，方便调试，这种机制就是call dump。下面简单介绍powerpc环境中如何实现call dump。内核态call dump内核态有三种出错情况，分别是bug, oops和panic。bug属于轻微错误，比如在spin_lock期间调用了sleep，导致潜在的死锁问题，等等。oops代表某一用户
Linux内核Call Trace调试分析方法
da_xiang的博客
01-15 3455
讲述了Call Trace 的调试方法
linux内核模块call trace格式解析
jinking01的专栏
05-20 1万+
今天测试编写的内核模块进行文件读写，结果失败。通过dmesg查看内核输出，结果如下： [37725.645804] I am here! and the user buf size is 1024 [37725.645812] The last data record position: 4096 current postion:0 [37725.645818] buff size 8 [37725.647660] BUG: unable to handle kernel
call trace定位方法之一
m0_61269311的博客
08-14 7773
calltrace是内核Oops问题的一部分，它是内核在发生错误时输出的一段调用栈信息，用于帮助开发人员定位问题。calltrace一般都是软件导致的问题。calltrace是提醒出现这个问题的风险性，而不是等出现这个问题才报calltrace，所以并不是所有的calltrace都会导致系统挂死。导致calltrace的原因有很多，常见的有：踩空指针，访问不存在的地址空间，中断异常等。addr2line -r tpm_tis_spi.ko 0x32c（最后的参数就是算出来的实际的符号的地址）
[笔记分享] [Exception] 内核空间异常之Call Stack解析
Kris Fei's blog
09-11 5109
1.1 介绍这一章我们主要对如何分析oops做些描述，以及说下目前我知道的方法。 当然，这里以以下例子来描述。1.2 定位某一行首先要找到发生exception的函数，虽然bug并不一定是这个函数引起的，而是经过函数一级级传下来造成。但总要知道出错的最终点吧.Call flow为 ret_fast_syscall -> vfs_read -> syfs_read -> sysfs_read_fil
[ 106.886575] Call Trace: [ 106.889149] [<8e2e3600>] PpeTxHandler+0xb0/0xb54 [hw_nat] [ 106.894681] [<812e44c0>] mtk_start_xmit+0x1d0/0x99c [ 106.899646] [<815ed5b0>] dev_hard_start_xmit+0x2d0/0x3a0 [ 106.905016] [<8160de4c>] sch_direct_xmit+0xb0/0x264 [ 106.909939] [<815edaf4>] __dev_queue_xmit+0x360/0x670 [ 106.915096] [<81744b34>] vlan_dev_hard_start_xmit+0xa4/0x198 [ 106.920832] [<815ed5b0>] dev_hard_start_xmit+0x2d0/0x3a0 [ 106.926219] [<815edc94>] __dev_queue_xmit+0x500/0x670 [ 106.931350] [<8172cbcc>] br_dev_queue_push_xmit+0x118/0x160 [ 106.936997] [<8172cc50>] br_forward_finish+0x3c/0xb0 [ 106.942035] [<8172cd0c>] __br_deliver+0x48/0xb8 [ 106.946641] [<8172d54c>] br_flood_deliver+0x24/0x30 [ 106.951590] [<8172a4c0>] br_dev_xmit+0x128/0x254 [ 106.956283] [<815ed5b0>] dev_hard_start_xmit+0x2d0/0x3a0 [ 106.961673] [<815edc94>] __dev_queue_xmit+0x500/0x670 [ 106.966824] [<8171e7e8>] packet_sendmsg_spkt+0x3d0/0x46c [ 106.972223] [<815cf6f4>] SyS_sendto+0x128/0x150 [ 106.976847] [<810078d8>] syscall_common+0x30/0x54解释这个calltrace的含义并画出流程图
最新发布
03-29
根据引用[3]，start_kernel调用rest_init，这说明内核启动时的函数调用层次较深，但用户的问题更侧重于通用的Call Trace解析，而不仅仅是启动过程。 步骤一：获取Call Trace信息。这通常来自内核日志，比如dmesg的...
Android逆向安全-无侵入找关键call之trace日志分析大法
大星星的专栏
01-07 3599
标题 找关键call是逆向的基本技能和分析目标，找到关键call后便可以进一步利用。在安卓App的逆向分析中，人肉逆向分析虽说不难，但是繁琐，特别是现在App体积动辄几十MB甚至几百MB，反编译出的jar或者smali文件相当多，找关键call无疑是大海捞针。 那么有什么方法可以快速找关键call呢？ 之前介绍过两个方法： 一个是插桩日志分析法，一个是借助加固的方法。 插桩日志分析法，理解起来比较...
不使用调试器查看堆栈的调用情况（CallTrace）
jphaoren的专栏
04-13 1879
转自：http://www.xue5.com/itedu/200707/127638.html 程序不大，调了三个小时，自己有必要在强化下对指针的理解：（ 原理：函数调用的时候会建立栈帧，其大致存放如下 压栈传入的参数2 压栈传入的参数1 ------------------------ 函数返回时的地址 ------------------------ 栈帧 ---------
linux kernel debug 之 CallTrace
大张
07-15 1万+
这篇文章是基于上次UWB(WUSB) wireless debug 的一个问题，然后引申出来的一个话题，对kenel有一定理解的同学可能会有一定的帮助。 --其实这个问题，个人认为，这个个CallTrace会一起down机，cpuhold的等问题，还是一个很大的问题。不过从一般意义上来讲，他是个warning我们可以不用管他。但谁让自己是做技术的呢，没办法，眼里容不得沙子。来吧干货。 1.  
Scripts:找出后台trace文件的脚本sess_user_trace_file_location.sql
elvis的Oracle Lab
06-03 698
-- +----------------------------------------------------------------------------+ -- |                          Jeffrey M. Hunter                                 | -- |                      jhunter@
linux内核bug问题排查过程详细报告
星.云计算
12-16 4159
Linux Kernel BUG:soft lockup CPU#1 stuck分析 1.线上内核bug日志 kernel: Deltaway too big! 18428729675200069867 ts=18446743954022816244 write stamp =18014278822746377 kernel:------------[ cut here ]---------...
call trace 格式
o_alpha的博客
04-30 1358
Call Trace: [<123>] a+0x10/0x8 [<234>] b+0x0/0x10 a具体出错的函数，0x8是a的长度，0x10是出错的指令在知a里的偏移。
linux call trace地址,linux kernel debug 之 CallTrace
weixin_29790467的博客
05-15 1528
这篇文章是基于上次UWB(WUSB) wireless debug 的一个问题，然后引申出来的一个话题，对kenel有一定理解的同学可能会有一定的帮助。--其实这个问题，个人认为，这个个CallTrace会一起down机，cpuhold的等问题，还是一个很大的问题。不过从一般意义上来讲，他是个warning我们可以不用管他。但谁让自己是做技术的呢，没办法，眼里容不得沙子。来吧干货。1.Kernel...
如果perf给出的callchain是错误的，该怎么处理？
承刚
11-06 2056
perf有时给出的callchain是错误的，这里简单说一下原因及解决方法。 callchain时指函数的调用路径。通常我们也把它称为call trace。 很多同学在使用perf看热点函数的调用路径时，都发现perf给出的callchain是一堆混乱的地址，或者给出的callchain根本不对。 我们先来解释一下perf获得callchain的方法：如果我们需要取callcha
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值