linux下程序崩溃后记录调用堆栈.以便查找问题

最新推荐文章于 2025-10-08 22:47:11 发布
原创 最新推荐文章于 2025-10-08 22:47:11 发布 · 6.6k 阅读 · 4 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#linux #c

本文介绍了一种在Linux环境下，当程序崩溃时手动记录堆栈信息的方法，包括注册信号处理函数、使用backtrace获取堆栈调用地址列表、利用backtrace_symbols获取函数名和偏移量，并通过addr2line获取代码文件名和行数。
部署运行你感兴趣的模型镜像

 在linux下程序崩溃后，一般都会有coredump,但是这个coredump有时候会被截断（尽管已经设置了ulimit -c unlimited也会），导致没法用gdb查看问题所在。

只好想办法在程序崩溃时自己记录下堆栈信息。

思路是:

1.注册信号处理函数，处理所有默认行为为终止程序的信号。

2.用backtrace得到发生问题的线程的堆栈调用地址列表。

3.用backtrace_symbols得到每个地址对应的函数名和偏移量.

4.用addr2line 功能得到偏移量对应的代码文件名和行数(需要在编译的时候设置-g -rdynamic)，并将其输出重定位到文件中。

由于addr2line是一个程序名而不是可供c++调用的函数，所以需要重定位cout。

 

您可能感兴趣的与本文相关的镜像

ACE-Step

ACE-Step

音乐合成
ACE-Step

ACE-Step是由中国团队阶跃星辰（StepFun）与ACE Studio联手打造的开源音乐生成模型。 它拥有3.5B参数量，支持快速高质量生成、强可控性和易于拓展的特点。 最厉害的是，它可以生成多种语言的歌曲，包括但不限于中文、英文、日文等19种语言

ghosthjt
关注
使用反汇编工具IDA查看动态库的汇编代码上下文，结合安卓系统生成的Tombstone文件，快速定位安卓app程序底层C++库的崩溃问题
dvlinker的技术专栏
08-14 3万+
使用IDA反汇编工具查看汇编代码上下文，结合安卓系统自动生成的Tombstone文件，去分析安卓app程序底层C++模块的崩溃问题。
游戏大厂如何定位闪退？Native崩溃堆栈查找全解析
本博客聚焦游戏开发技巧、创业实战心得及大学热门课程干货。这里既有技术深度，也有思维广度，无论你是开发者、创业者还是高校学子，都能在这里找到适合自己的成长之路！
04-29 963
游戏大厂闪退问题定位全流程解析 摘要： 游戏闪退（Crash）是影响用户体验和产品口碑的关键问题，尤其是Native层崩溃难以定位。大厂处理闪退的完整流程包括：1）通过Crash SDK实时采集崩溃堆栈和设备信息；2）使用符号表文件解析机器码地址为可读代码位置；3）通过聚类分析找出高频崩溃模式；4）在测试环境复现问题场景；5）修复并验证效果。整个过程依赖专业的Crash分析平台、符号化工具和大数据归因能力，是游戏技术团队的核心竞争力。高效解决闪退问题能显著提升产品稳定性和用户留存率。
linux 打印堆栈日志_更智能的奔溃日志：stackprinter
weixin_32869687的博客
12-27 595
本工具将打印带有代码上下文和附近变量值的回溯信息/调用的堆栈。它回答了我对交互式调试器的大多数疑问: 它在代码中的什么地方出现，相关的局部变量中有什么，以及为什么那个函数要用这些参数调用。它不是一个完全成熟的错误监控系统(https://sentry.io/welcome/ )，而只是Python内置崩溃消息的一个更有用的版本。有时候，我会在本地使用它来代替调试器，但是当我的代码运行在...
Linux崩溃问题定位办法总结二
2501_93311146的博客
10-08 1455
嵌入式Linux项目中启用coredump功能可有效定位程序崩溃问题。
Linux获取崩溃栈信息,C++ crash 堆栈信息获取
weixin_31556371的博客
05-08 1793
最近在做程序异常时堆栈信息获取相关工作，上一篇文章成功的在程序creash时写下了dump文件，而有些情况写dump文件是不可以的，比如在jni开发时，C++只做底层处理，而整个项目是android工程，这个时候dump文件没有了优势，那么只能在程序creash时把内存信息打印出来，获取输出到文件中。下面讲述下我在做堆栈信息获取时的一些经验：从名称上就可以看出，文章2是生成dump文件的，我的上一...
linux内核中打印栈回溯信息 - dump_stack()函数分析
落尘纷扰的专栏
05-08 2万+
当内核出现比较严重的错误时，例如发生Oops错误或者内核认为系统运行状态异常，内核就会打印出当前进程的栈回溯信息，其中包含当前执行代码的位置以及相邻的指令、产生错误的原因、关键寄存器的值以及函数调用关系等信息，这些信息对于调试内核错误非常有用。
Linux程序崩溃打印堆栈信息
qq_43482971的博客
11-09 1558
** Linux。程序崩溃打印堆栈信息 ** main：signal(SIGSEGV,sig); static void sig(int sig) { int i int nptrs void *buffer[100] chat **strings nptrs=backtrace(buffer,100) strings=backtrace_symbol(buffer,nptrs) QString buff; for(i=0;i<nptrs;++i) { 打印出来就行 } free(strings) e
Linux环境抓取程序异常退出（崩溃）的堆栈信息（core dump）
weixin_45844208的博客
07-23 4649
本文介绍了配置Linux环境程序进程发生异常（崩溃）退出时生成core文件，使用gdb命令对程序异常退出生成的core文件进行堆栈信息的调试，使用gdb命令对程序或者程序PID值进行崩溃堆栈信息调试。
精选资源
Linux应用程序调试技术的研究.pdf
09-06
在调试过程中，开发者需要关注错误信号的处理，理解堆栈结构，以及如何解析core文件以获取程序崩溃时的状态信息。 此外，为了预防和减少程序错误，开发者应该遵循良好的编程实践，例如编写可读性强的代码，使用静态...
内存不足引发C++程序闪退崩溃问题的分析与总结
dvlinker的技术专栏
11-25 1万+
本文在多年项目实践的基础上，详细总结一下内存不足的相关问题场景以及内存不足引发程序异常的具体原因，供大家借鉴或参考。
Stack overflow 线程栈溢出异常，程序崩溃在汇编代码 test dword ptr [eax],eax 上的问题排查
热门推荐
dvlinker的技术专栏
07-15 3万+
本文详细讲述线程栈溢出异常，程序崩溃在汇编代码test dword ptr [eax],eax上问题的排查过程。
浅析Linux下利用coredump技术追查进程崩溃原因
09-14
主要介绍了Linux下利用coredump技术追查进程崩溃原因,本文给大家介绍的非常详细，具有一定的参考借鉴价值，需要的朋友可以参考下
linux 崩溃无堆栈信息,linux c开发: 程序崩溃时保存堆栈信息并解析具体代码行
weixin_29893445的博客
05-08 891
写服务器程序最怕的是百分之一的概率崩溃了，你却不知道为啥，想重现又重现不出来。所以在崩溃时将当时的堆栈保存下来非常重要。网上有很多文章讲解怎么保存，但我使用了发现可以保存，但是没有函数名称和行号，仍然没法定位问题。在stack overflow上有人说只有动态库的代码才能显示出函数名和行号，想完整显示还需要使用某某第三方开源库，不过我幸好发现使用addr2line命令可以将文件名和行号显示出来，轻...
【linux】grep命令检索大批量日志中的堆栈日志
weixin_30553065的博客
05-13 663
记得3年前，我为了查看100M日志文件里面的错误堆栈信息，百度了许久都毫无结果 没想到今天再次百度时，一下子看到了grep -A 命令，激动不已。 原来只需要用， grep -A 100 'KeyWord' file grep -B 100 'KeyWord' file grep -C 100 'KeyWord' file 就能看到关键字前后多少行的错误日志，真是...
Linux 上日志记录崩溃函数调用栈方法
zhouguoqionghai的博客
05-12 1522
背景：线上环境进程崩溃，运维为了不背锅，要求崩溃之后立马将进程拉起。然而发现有个问题：一旦运维将进程拉起之后，之后使用崩溃的 core 文件来进行分析时，符号信息都丢失，看到的都是问号。 但是，如果崩溃之后未被拉起，可以正常的看到符号。 后来发现，是运维启动进程的 shell 脚本，每次启动之前，会将需要加载的部分业务相关的 so 文件，文件名字修改（名称里加上了时间戳，类似 lib20200423002608_xxxx.so 这种）。名称被修改之后，gdb 自然没法加载加载这个 so 文件。.
linux下使用backtrace记录程序崩溃时的堆栈信息，并进行分析
Turn X7
05-05 1927
linux下使用backtrace记录程序崩溃时的堆栈信息，并进行分析
linux 崩溃无堆栈信息,Linux内核崩溃调用堆栈长度
weixin_42513209的博客
05-08 445
任何人都可以告诉我如何轻松增加在Linux内核崩溃时报告的调用堆栈函数的数量？Linux内核崩溃调用堆栈长度目前我看到：[<80100ca8>] (free_buffer_head) from [<80100d2c>] (try_to_free_buffers+0x7c/0xbc)[<80100d2c>] (try_to_free_buffers) from [...
在linux代码中打印函数调用的堆栈的方法
ykqnjust的专栏
08-24 1万+
<br />之前一直有这样的需求，当时问到，也没搜到方法，现在竟然既问到了，也搜到了，哎，世事真是不能强求啊！<br /> <br />在linux内核调试中，经常用到的打印函数调用堆栈的方法非常简单，只需在需要查看堆栈的函数中加入：<br />dump_stack();或 __backtrace();即可。<br /> <br />dump_stack()在~/kernel/ lib/Dump_stack.c中定义<br /> <br />void dump_stack(void)<br />{<br /
linux 进程崩溃 堆栈,c – 当程序崩溃时如何自动生成堆栈跟踪
weixin_30695909的博客
05-03 465
对于Linux和我相信Mac OS X,如果你正在使用gcc,或任何使用glibc的编译器,你可以使用execinfo.h中的backtrace()函数来打印堆栈跟踪并在出现分段错误时正常退出.文档可以在in the libc manual找到.这是一个示例程序,它安装一个SIGSEGV处理程序,并在它发生段错误时将堆栈跟踪打印到stderr.这里的baz()函数会导致触发处理程序的段错误：#in...
linux系统的程序崩溃数据文件core_myapp.11891如何读取？
最新发布
11-30
<think> 首先，用户的问题是：“我想查找在Linux系统中读取程序崩溃数据文件core_myapp.11891的方法 请问Linux系统读取程序崩溃数据文件core_myapp.11891的方法” 核心是：用户想知道如何读取Linux系统中的程序崩溃数据文件，具体文件名为core_myapp.11891。这应该是一个core dump文件，用于调试程序崩溃。 从系统级指令看： - 所有行内数学表达式必须使用$...$格式。 - 独立公式使用$$...$$格式并单独成段。 - LaTeX语法正确。 - 使用中文回答。 - 生成相关问题。 - 在回答中引用的段落末尾自然地添加引用标识，例如[^1]。 用户可见层的指令：回答结构清晰，帮助用户逐步解决问题，保证回答真实可靠。 现在，查看提供的引用： - 引用[1]：讨论了kernel.core_pattern的设置，core dump文件的生成和存储。提到了sysctl命令查看和修改kernel.core_pattern，以及格式化占位符。 - 引用[2]：关于构建.AppImage格式的Linux可执行程序，提到linuxdeployqt工具。但似乎与core dump无关。 - 引用[3]：关于Linux文件系统，如vfs、procfs等。不直接相关。 - 引用[4]：关于NUMA内存限制的设置，如zone_reclaim_mode和min_unmapped_ratio。不直接相关。 - 引用[5]：关于SELinux ACL工具iaclabel，用于设置文件的安全标记。不直接相关。 用户的问题核心是读取core dump文件，而不是生成或设置。所以，引用中只有引用[1]部分相关。 用户提到的文件是core_myapp.11891，这看起来像是一个core dump文件，可能由kernel.core_pattern设置生成，其中%e是进程名，%p是PID。 用户想“读取”这个文件，意思应该是如何分析或调试这个core dump文件。 在Linux中，读取core dump文件通常使用调试器，如gdb（GNU调试器）。 步骤应该包括： 1. 确保core dump文件已生成并存在。 2. 安装必要的调试工具，如gdb。 3. 使用gdb加载可执行文件和core dump文件来分析崩溃原因。 具体命令： - 首先，找到core dump文件的位置。用户指定了文件名core_myapp.11891，所以假设它存在。 - 然后，使用gdb命令：gdb /path/to/myapp /path/to/core_myapp.11891 - 之后，在gdb中使用命令如`bt`（backtrace）来查看堆栈跟踪。 从引用[1]中，我可以引用部分内容，因为它涉及core dump的生成。 例如，引用[1]说：“内核会根据 kernel.core_pattern 的设置生成 core dump 文件”，这可以用于解释core dump文件是如何产生的。 用户的问题是读取，所以重点在分析。 结构清晰的回答： - 介绍core dump文件。 - 步骤1：确认core dump文件存在。 - 步骤2：使用gdb分析。 - 提供示例命令。 - 解释输出。 生成相关问题。 在回答中，引用相关段落末尾添加引用标识。 例如，当提到kernel.core_pattern时，可以引用[^1]。 现在，构建回答。 大纲： 1. **介绍core dump文件**：解释什么是core dump文件，为什么需要它。引用引用[1]的部分。 2. **检查core dump文件存在**：用户可能已经知道文件存在，但建议确认位置。 3. **安装调试工具**：如果需要，建议安装gdb。 4. **使用gdb分析**：详细命令。 5. **示例**：给出一个简单的例子。 6. **相关问题**：生成相关问题。 使用中文回答。 数学表达式：用户的问题中没有明显的数学表达式，但如果有，比如提到PID或其他数字，确保格式正确。但这里可能不需要。 独立公式：可能不需要。 确保LaTeX语法正确：在这个上下文中，可能不涉及复杂数学。 回答结构： - 开头：直接回应用户问题。 - 步骤：分步骤解释。 - 结尾：相关问题。 </think>### Linux系统中读取程序崩溃数据文件core_myapp.11891的方法 在Linux系统中，程序崩溃时生成的文件（如`core_myapp.11891`）称为core dump文件，它包含了程序崩溃时的内存状态、寄存器值、堆栈跟踪等信息，用于调试和分析崩溃原因。核心工具是GNU调试器（GDB），它允许您加载可执行文件和core dump文件进行交互式分析。下面我将逐步解释如何读取和分析该文件，确保过程清晰可靠。 #### 步骤1: 确认core dump文件存在和位置 - **检查文件是否存在**：首先，确认core dump文件`core_myapp.11891`位于文件系统中。文件名通常包含进程名（`myapp`）和进程ID（`11891`），这由系统参数`kernel.core_pattern`控制，该参数定义了core dump的存储路径和命名格式（例如，`/var/crash/core.%e.%p.%h.%t`表示将文件保存在`/var/crash`目录，其中`%e`是进程名、`%p`是PID）[^1]。 - 使用命令行搜索文件： ```bash find / -name "core_myapp.11891" 2>/dev/null # 搜索整个文件系统，忽略错误 ``` - 如果文件不存在，可能core dump未启用。检查系统设置（见下文提示）。 - **验证core dump生成机制**：Linux内核在进程崩溃时生成core dump文件，具体行为取决于`kernel.core_pattern`的配置。您可以通过以下命令查看当前设置： ```bash sysctl kernel.core_pattern # 输出示例：kernel.core_pattern = /var/crash/core.%e.%p.%h.%t ``` 如果输出以管道符（`|`）开头，表示core dump被重定向到处理程序（如`systemd-coredump`），此时文件可能存储在系统日志或特定服务目录中[^1]。 #### 步骤2: 准备分析环境 - **安装GDB调试器**：如果未安装GDB，请先安装它。GDB是标准调试工具，支持加载core dump文件。 - 在基于Debian的系统（如Ubuntu）中： ```bash sudo apt update && sudo apt install gdb ``` - 在基于RHEL的系统（如CentOS）中： ```bash sudo yum install gdb ``` - **获取可执行文件**：分析core dump需要原始可执行文件（即崩溃的程序`myapp`）。确保您有该文件的副本，并且其版本与生成core dump时一致（包括编译选项和符号表）。如果可执行文件已更新，分析可能不准确。 - 如果`myapp`是自定义程序，检查其路径（如`/usr/local/bin/myapp`）。 - 提示：编译程序时添加`-g`选项（如`gcc -g -o myapp source.c`），可以包含调试符号，便于GDB显示详细错误信息。 #### 步骤3: 使用GDB加载和分析core dump文件 - **基本命令**：运行GDB，指定可执行文件和core dump文件路径。语法为： ```bash gdb /path/to/myapp /path/to/core_myapp.11891 ``` 例如，如果可执行文件在`/usr/local/bin/myapp`，core dump在`/var/crash/core_myapp.11891`： ```bash gdb /usr/local/bin/myapp /var/crash/core_myapp.11891 ``` 执行后，GDB会进入交互模式。 - **关键分析命令**：在GDB交互环境中，使用以下命令提取崩溃信息： - **查看堆栈跟踪（backtrace）**：命令`bt`显示函数调用序列，帮助定位崩溃点。 ``` (gdb) bt # 输出示例： # #0 0x00007f5d6e8c3457 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 # #1 0x00007f5d6e8c4b48 in __GI_abort () at abort.c:89 # #2 0x000055a5b5d6c1a3 in main (argc=1, argv=0x7ffd5e1f0a88) at myapp.c:10 ``` 此输出显示崩溃发生在`myapp.c`文件的第10行（如空指针解引用或除零错误）。 - **检查变量和寄存器**： - `info registers`：显示CPU寄存器值。 - `print variable_name`：打印特定变量值（如`print *ptr`）。 - **退出GDB**：输入`quit`退出。 - **常见分析场景**： - 如果GDB提示“Missing debug symbols”，表示可执行文件缺少调试信息。请重新编译程序并添加`-g`选项。 - 如果core dump文件损坏，GDB会报错“Core was generated by...”。确保文件未被截断（检查大小：`ls -l /path/to/core_myapp.11891`）。 #### 步骤4: 解读结果和常见问题处理 - **崩溃原因**：GDB的`bt`输出通常包含错误信号（如`SIGSEGV`表示段错误）。常见原因包括： - 内存访问越界（如空指针）。 - 堆栈溢出或资源耗尽。 - **权限问题**：如果无法读取core dump文件（如权限不足），使用`sudo`运行GDB，或调整文件权限： ```bash sudo chmod +r /path/to/core_myapp.11891 # 添加读取权限 ``` - **core dump未生成的原因**： - 系统限制：使用`ulimit -c`检查core文件大小限制（`ulimit -c unlimited`可临时启用）。 - `kernel.core_pattern`设置错误：参考引用[1]，修改该参数（如`sudo sysctl -w kernel.core_pattern=/var/crash/core.%e.%p.%h.%t`）[^1]。 #### 提示：为什么core dump文件重要？ Core dump文件是调试的关键，它允许您事后分析崩溃，无需重现问题。在开发环境中，它便于快速定位代码错误；在生产环境中，结合日志可提高系统稳定性[^1]。如果`myapp`是Qt等框架应用，确保编译时启用调试支持，以避免符号缺失[^2]。 ### 相关问题 1. 如何配置Linux系统以生成core dump文件？ 2. 除了GDB，还有哪些工具可以分析core dump文件？ 3. 如何处理core dump文件权限或存储空间不足的问题？ 4. 在容器化环境（如Docker）中如何获取和分析core dump？ [^1]: 当进程因错误（如段错误、除零错误）崩溃时，内核会根据 kernel.core_pattern 的设置生成 core dump 文件，并存储到指定位置。 [^2]: 编译应用时使用Release模式可能优化掉调试符号，建议在调试时包含符号信息
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值