dmesg配合addr2line

最新推荐文章于 2025-04-08 16:11:56 发布

ManualZhang

最新推荐文章于 2025-04-08 16:11:56 发布

阅读量100

点赞数

文章标签： linux bug

本文链接：https://blog.youkuaiyun.com/weixin_44789033/article/details/132916498

版权

本文介绍了在Linux系统中，通过`addr2line`命令结合`dmesg`和文件操作，追踪崩溃线程回溯到崩溃点的具体源代码行的过程。步骤包括查看内存错误信息、定位崩溃的库文件和函数地址。

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

直接上命令

addr2line -e  你的崩溃文件(注意路径)  你的崩溃偏移量  -f -a -C -p

线程崩溃了

dmesg

在这里插入图片描述
拿ip地址减去程序地址

cd到根目录下,寻找崩溃的程序文件，具体文件可能是一个库，也有可能是一个可运行文件

cd /
find -name libpthread-2.31.so
cd /usr/lib/x86_64-linux-gnu/
addr2line -e libpthread-2.31.so B08E -f -a -C -p

在这里插入图片描述

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

ManualZhang

关注关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

dmesg和addr2line命令定位段错误

线上幽灵

07-02

1145

没有core文件下，通过dmesg、addr2line命令定位段错误

使用 dmesg 和 addr2line 分析程序 core 原因

码农

04-13

4132

今天遇到这样一种情况：发现进程 tagent 在发送响应时退出了，退出原因未知，因为没有 core 文件，无从分析。core 文件生成目录和 ulimit 都没有任何问题，就是不生成 core 文件：$ cat /proc/sys/kernel/core_pattern core.%p_%e$ ulimit -c unlimited写了个小程序也能生成 core, 没有 core 文件，只能另觅他径

参与评论您还未登录，请先登录后发表或查看评论

利用dmesg和addr2line来对（动态库里的）段错误进行调试

木牛的博客

06-16

1141

工作中，我们在varnish的基础上，利用vmod机制，实现了一个可以定制策略，且策略可自动加载而不需重新启动引擎的cache（平时，大家对varnish的利用，cache策略都定义在一个vcl配置文件中，每次对策略进行修改，都需要重新启动varnish，从而使得策略生效，且当部署在varnish后面的站点很多时，不方便对每站点的cache策略进行个性化的定制），这里各种策略的控制以及加载都实现在一个vmod模块里（libvmod_ngcache.so）,很开心，产品上线了。那么问题来，（挖掘机技术那家强？

使用addr2line工具定位导致程序崩溃的源码位置

qq_38060778的博客

04-08

692

在Linux开发中，程序崩溃时通常只能获取到十六进制内存地址。通过addr2lineip:4005f5。

利用dmesg和addr2line来重现bug

手边笔记

03-03

1万+

利用dmesg和addr2line来重现bug 有些时候，我们的程序crash了，但是我们没有保存core dump信息，这时如果我们想要知道程序在哪个位置出错，就不是那么容易了。下面有一种方法，可以大致判断出程序出错的大致位置。 1.用dmesg查找出错的代码段地址。命令格式： dmesg | grep program_name其中program_name是可执行文件，

addr2line

weixin_42082222的博客

03-02

2577

binutils工具集之---addr2line addr2line用于得到程序指令地址所对应的函数，以及函数所在的源文件名和行号。在不少嵌入式开发环境中，编译器的名称往往不是gcc，而是想arm-rtems-gcc这样的，对于这种命名形式的编译器，读者通常可以找到arm-rtems-addr2line ，arm-rtems-objdump等相应名称的工具，这是GNU工具集的一...

C++ 调试技术：addr2line

个人博客

08-21

2305

最常用的调试C++程序的方法是使用IDE,，比如说vs,clion。打断点，debug模式跑。稍微先进一点的是使用gdb进行调试。 gdb调试使用到的技术就比较多了，以后详细介绍。今天看到一个神奇的命令addr2line，这个命令可以在程序 core dump的时候告诉你程序在哪一行出错。示例代码如下： int main(void) { char *str; /* Stor...

Linux生成dumpcore并进行调试,以及addr2line的用法

qq_39937902的博客

03-15

1000

1) 在终端中输入ulimit -c 如果结果为0，说明当程序崩溃时，系统并不能生成core dump。2) 使用ulimit -c unlimited命令，开启core dump功能，并且不限制生成core dump文件的大小。如果需要限制，加数字限制即可。ulimit - c 10243) 默认情况下，core dump生成的文件名为core，而且就在程序当前目录下。新的core会覆盖已存在的...

linux运行程序段错误吐核,如何在没有core文件的情况下用dmesg+addr2line定位段错误...

weixin_32254411的博客

05-03

892

前言在现网环境下，程序奔溃后不一定会留下core文件，原因有很多，比如存储空间不足就是其中一个常见的原因。此时我们只能依据linux记录的错误日志来定位问题。涉及linux命令本文涉及以下几条命令1. dmesg命令，用于获取程序出错时的堆栈地址1)dmesg |grep -e 'segfault|general'可以通过该命令过滤出发生崩溃的程序，以及对应的堆栈信息。之前看网上的其他文章仅过滤s...

addr2line命令使用

miss33445210的专栏

01-11

7434

用 Addr2line 可以将函数地址解析为函数名 Addr2line 工具（它是标准的 GNU Binutils 中的一部分）是一个可以将指令的地址和可执行映像转换成文件名、函数名和源代码行数的工具。这种功能对于将跟踪地址转换成更有意义的内容来说简直是太棒了。要了解这个过程是怎样工作的，我们可以试验一个简单的交互式的例子。（我直接从 shell 中进行操作，因为这是最简单地展示

Linux addr2line 命令

mayue_web的博客

02-09

7363

描述Linux下addr2line命令用于将程序指令地址转换为所对应的函数名、以及函数所在的源文件名和行号。当含有调试信息(-g)的执行程序出现crash时(core dumped)，可使用addr2line命令快速定位出错的位置。如果无法确定文件名或函数名，addr2line将在它们的位置打印两个问号；如果无法确定行号，addr2line将打印0或一个问号。查看使用和帮助手册参数说明-a --addresses：在函数名、文件和行号信息之前，显示地址，以十六进制形式。

linux 内核 addr2line,linux应用程序调试指南(addr2line)

weixin_31849853的博客

04-30

472

调试zSeries上的Linux应用程序类似于调试其他体系结构上的Linux应用程序。对于有经验的Linux开发人员，最大的挑战是理解新的系统体系结构。对于刚接触Linux的大型机开发人员，掌握新的调试工具似乎是一项令人畏惧的任务。不要害怕。本文将提供Linux addr2line一些有用的提示来帮助您入门。UserDebug日志记录调试一个崩溃的程序的第一步是弄清哪里出了错。zSeries上的L...

addr2line的使用

贾亮的专栏

07-24

2041

在使用Linux的glibc中的backtrace时，有时打印不出来堆栈中的函数名，只有内存地址，所以需要使用到add2line. 下面是例子： [jialiang]$ addr2line -e YourExeFileWithDebugFlag -f 0x416090 #输入backtrace输出的内存地址 YourMethodName #add2lien会给出函数名 YouFile

Linux下addr2line命令用法

最新发布

05-14

<think>好的，用户遇到了在Linux系统中第二次访问I2C设备导致系统崩溃的问题。我需要结合之前提供的引用信息来分析可能的原因和解决方案。首先，用户提到的引用[2]中出现了Oops错误，具体是在访问GPIO时发生内核页表错误。这可能涉及到硬件访问冲突或者驱动代码中的竞态条件。I2C适配器作为硬件控制器驱动，如果注册或注销不当，可能会导致系统不稳定。第一次访问可能正常，但第二次访问时资源可能已被释放或冲突，导致崩溃。可能的原因有几个：一是I2C适配器未正确初始化或释放，导致重复访问时资源冲突；二是GPIO模拟I2C时存在时序问题，尤其是在多线程或中断环境下，没有正确处理锁机制；三是内存管理问题，如指针错误或内存泄漏，第二次访问时触发异常。解决方案方面，需要检查I2C适配器的注册和注销流程，确保每次访问前适配器处于就绪状态。其次，查看GPIO操作是否正确，是否存在未正确释放的引脚或配置错误。此外，检查内核日志中的Oops信息，定位具体的函数调用和代码位置，分析是否涉及竞态条件或内存错误。可能需要使用互斥锁或信号量来保护共享资源，确保并发访问的安全性。最后，更新或修复驱动代码，确保与当前内核版本兼容，避免已知的BUG。</think>### Linux I2C二次访问崩溃问题分析与解决方案 #### 一、常见原因分析 1. **适配器资源未正确释放** - 首次访问后未释放I2C总线控制权导致二次访问冲突 - 适配器驱动未实现完整的`probe()`/`remove()`方法链[^1] 2. **GPIO模拟时序缺陷** - GPIO引脚复用配置冲突（如未正确设置`gpio_request`） - SDA/SCL线电平状态检测异常（如引用[2]中的`gpio_get_value`错误） 3. **内核并发访问问题** - 缺少互斥锁保护（`mutex_lock`） - 中断与进程上下文资源竞争 4. **内存管理异常** - 用户空间指针未正确拷贝（`copy_to_user`/`copy_from_user`） - DMA缓冲区未对齐或越界 #### 二、诊断步骤 1. **分析Oops日志** ```bash dmesg | grep -i "i2c\|gpio\|BUG" ``` - 重点关注PC指针位置（如引用[2]中的`c0250180`） - 使用`addr2line`工具定位问题代码 2. 检查硬件配置： ```bash # 查看I2C设备树配置 dtc -I fs /proc/device-tree | grep i2c # 检查GPIO分配状态 cat /sys/kernel/debug/gpio ``` 3. 验证总线状态： ```bash i2cdetect -l # 列出所有适配器 i2cget -f <bus> <chip_addr> # 测试设备响应 ``` #### 三、解决方案 1. **驱动代码增强** ```c static DEFINE_MUTEX(i2c_lock); // 声明互斥锁 static int i2c_transfer_protected(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) { int ret; mutex_lock(&i2c_lock); // 加锁 ret = __i2c_transfer(adap, msgs, num); mutex_unlock(&i2c_lock); // 解锁 return ret; } ``` 2. **GPIO模拟时序修正** ```c // 正确的GPIO获取/释放流程 static int i2c_gpio_init(void) { if (gpio_request(sda_gpio, "i2c-sda")) { pr_err("SDA GPIO %d request failed\n", sda_gpio); return -EBUSY; } gpio_direction_input(sda_gpio); // 正确设置方向 // 同理处理SCL... } ``` 3. **适配器注册增强** ```c static struct i2c_adapter i2c_gpio_adapter = { .owner = THIS_MODULE, .name = "i2c-gpio", .algo = &i2c_gpio_algo, .retries = 3, // 增加重试次数 }; static int __init adapter_init(void) { int ret = i2c_add_adapter(&i2c_gpio_adapter); if (ret) pr_err("Adapter registration failed: %d\n", ret); return ret; } ``` 4. **内存访问保护** ```c static long i2c_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) { struct i2c_msg user_msg; if (copy_from_user(&user_msg, (void __user *)arg, sizeof(user_msg))) { return -EFAULT; // 正确拷贝用户空间数据 } // 处理消息... } ``` #### 四、验证方法 1. 压力测试： ```bash # 连续访问测试 for i in {1..100}; do i2cget -y <bus> <chip_addr> <register> done ``` 2. 内核调试： ```bash echo 8 > /proc/sys/kernel/printk # 开启调试日志 echo -n "module i2c_dev +p" > /sys/kernel/debug/dynamic_debug/control ```