coredump文件栈破坏

最新推荐文章于 2025-07-20 18:07:20 发布
转载 最新推荐文章于 2025-07-20 18:07:20 发布 · 3.3k 阅读 · 8
文章标签：

#logging #output #脚本 #磁盘 #360 #c

本文分享了两种GDB调试技巧：当GDB失效时如何手动获取调用栈信息，以及如何执行GDB用户命令脚本。文章详细介绍了在面对内存型服务程序coredump或死锁等问题时，如何利用GDB的手动调试功能来恢复被破坏的调用栈。

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

分享两个GDB的小技巧：

1, GDB失效时手工得到stack；

2, GDB执行用户命令脚本；

调试内存型服务程序的有时会遇到core dump或死锁问题，且gdb或者pstack都无法显示调用栈（call stack）。这是因为线程的调用栈被破坏了，而调用栈存放了函数的返回地址，gdb解析函数返回地址（根据地址查找符号表）失败，gdb也没有进行容错处理，只要有一处地址解析失败就无法展开调用栈。然而幸运的是，调用栈往往只是部分被破坏，RSP堆栈寄存器中保存的值往往也是正确的，可以通过手工的方法恢复。具体做法如下：

(gdb) set logging on
Copying output to gdb.txt.
(gdb) x /2000a $rsp
0x426cb890: 0x0 0x4
0x426cb8a0: 0x426cb8c0 0x100
0x426cb8b0: 0x3e8 0x552f59 <_ZN5tbnet16EPollSocketEvent9getEventsEiPNS_7IOEventEi+41>
0x426cb8c0: 0x1823c8a000000011 0x0
0x426cb8d0: 0x0 0x0
0x426cb8e0: 0x0 0x0
...

如上图，类似”0x552f59 <_ZN5tbnet16EPollSocketEvent9getEventsEiPNS_7IOEventEi+41>”这样的代码符号看起来是有效的。通过所有看似有效的程序代码符号基本能够得出core dump时的调用栈。

当然，有可能出现core dump线程的调用栈被完全破坏的情况，通过上述方法恢复的信息仍然是无效的。由于每个线程堆栈地址空间的大小为10M，因此，线程之间互相破坏调用堆栈的可能性几乎是不存在的，此时，可以通过其它线程的调用栈分析其行为，往往也能找到线索。如果所有线程的调用栈都“看似被破坏”，那么，往往有两种可能：

a, 可执行程序和core文件对不上，被摆乌龙了，如发现core dump问题的时候可执行程序已经更新到最新版本，老版本没有保存；

b, 磁盘满了或者ulimit设置太小，导致core dump文件信息不全；

如果core文件对不上或者信息不全的问题，还可以通过dmesg命令找到程序core dump时的指令寄存器RIP的值，再通过addr2line获取程序最后执行的代码行。如：

[rizhao.ych@OceanBase036040 updateserver]$ dmesg | grep updateserver
updateserver[8099]: segfault at 0000000000000000 rip 0000000000500fbf rsp 000000004c296e30 error 4

[rizhao.ych@OceanBase036040 updateserver]$ addr2line -e updateserver 0000000000500fbf

/home/rizhao/dev/oceanbase/src/common/ob_base_server.cpp:222


http://www.nosqlnotes.net/archives/183


gexiao
关注
Coredump-N：多线程破坏栈的调试方法
mzhan017的博客
07-08 1293
栈空间的破坏，有一种可能性就是其他线程意外访问本线程的栈空间，导致数据破坏产生coredump。 这种是超级难找原因的一种，因为： - 非本线程的程序，也就是将代码走查这条路堵死， - 而且其他线程于本线程没有任何同步的机制，所以产生的机率可能非常的低。 如何调试： 使用gdb watch 功能，如果出现的概率非常低，就非常困难。如果每次都能复现，可以尝试这种方法； 使用mprotect函数保护被破坏的地址空间。但是这个函数只能整页的做保护； 如果出现的地方比较固定也可以尝试加一段时间的等待； 还可以尝试
无符号和栈破坏情况下coredump的分析方法
滴水穿石!
12-23 9582
原文:http://zhangzhibiao02005.blog.163.com/blog/static/37367820201482044137298/ 无符号和栈破坏情况下coredump的分析方法 昨天在上线的时候,出现了一个无符号和栈破坏的coredump.今天总结下这类core的追查方法: 1.打开core, gdb /tmp/gss core.20140911180
linux下异常coredump函数调用栈解析(二)
最新发布
牧羊人的博客
07-20 292
本文介绍了Linux下软件异常复位的定位方法，主要围绕core文件解析技术展开。文章详细讲解了gdb命令的使用，包括bt命令查看调用栈、i r命令分析寄存器值、以及disass命令反汇编指令。通过实例演示，展示了如何通过寄存器分析和汇编指令追溯空指针访问等常见问题。这些方法可以帮助开发者捕捉异常第一现场，快速定位软件复位根因，适用于复杂程序的调试场景。
善用GDB 调试一些函数栈被毁坏的问题
Adam040606的博客
07-26 1343
转自：http://blog.youkuaiyun.com/ontheline/article/details/16963817 最近查一些问题，这些问题的现象一开始难以解释，函数的参数地址在函数内部被传递给另外的函数，然后发现地址发生了改变，这样的情况称之为函数的栈被毁坏，导致无法重入。 然后被调用的函数里面，访问了非法的地址导致了segment fault,产生core dump文件。问题
Linux：GDB 调试一些函数栈被毁坏的问题
hhd1988的专栏
01-17 2538
Linux：GDB 调试一些函数栈被毁坏的问题
python栈溢出_GDB调试之二栈溢出
weixin_39915820的博客
12-08 430
linux下应用程序中经常会发生段错误段错误基本上是由于访问非法内存所导致的如栈溢出、数组越界访问、malloc/free内存所引起的。在linux下发生段错误时会生成core dump核心转储文件里面记录了发生段错误时的函数调用关系。ubuntu14.04下默认发生段错误时并不产生核心转储文件需要额外的配置通过命令ulimit -c查看是否允许的core dump文件大小。如果只是临时需要用到可...
【Linux】为什么程序崩溃没有产生 coredump 文件？
Sunnyside_
07-03 7374
【Linux】为什么程序崩溃没有产生 coredump 文件？ 文章目录【Linux】为什么程序崩溃没有产生 coredump 文件？一、现象二、什么是 coredump？三、coredump 原理四、coredump 文件的存储位置五、产生 coredump 文件的一些条件六、coredump 产生的集中可能情况七、解决方案 一、现象   先看一下代码： #include <unistd.h> #include <stdio.h> #include <stdlib.h>
无符号和栈破坏情况下coredump的分析方法 （牛逼） --- 081
happylzs2008的专栏
01-12 2141
https://blog.youkuaiyun.com/qazxlf/article/details/50385616 原文:http://zhangzhibiao02005.blog.163.com/blog/static/37367820201482044137298/ 无符号和栈破坏情况下coredump的分析方法 gdb 调试coredump文件中烂掉的栈帧的方法 https://blo...
linux解析core文件都是问号,coredump文件的产生分析
weixin_28718769的博客
04-30 1537
From： http://blog.sina.com.cn/s/blog_45497dfa0100mddb.html5. 一个小方法来测试产生core文件//---------------------------------------------------------------直接输入指令:kill -s SIGSEGV $$以前写的一个文档，有同学反馈不能用，恰好手头有一个堆栈被破坏的co...
Linux Debugging（五）: coredump 分析入門1
08-04
首先，通过`gdb a.out core.25992`命令，我们可以加载coredump文件并关联到相应的可执行文件（a.out），以便进行调试。接着，使用`bt`（backtrace）命令查看调用栈，但在此案例中，调用栈被破坏，无法提供有用信息。...
【C/C++】栈内存布局，堆栈内存被破坏的现象及可能原因
Michael
06-25 2028
为了避免堆栈内存被破坏，需要编写安全的代码，遵循内存管理的规范，使用安全的函数和算法，避免指针错误和并发问题等。当程序访问栈内存或堆内存时，如果访问了未分配的内存、已释放的内存、越界的内存等，就可能会导致堆栈内存被破坏的现象。指针错误：如果程序使用了未初始化的指针、空指针或野指针，可能会导致指针错误，进而导致堆栈内存被破坏。数据错误：如果堆栈内存被破坏导致数据被篡改，可能会导致程序出现错误的结果，影响程序的正确性。内存泄漏：如果程序没有正确释放动态分配的内存，可能会导致内存泄漏，进而导致堆栈内存被破坏。
堆栈溢出调试-gdb-例子
03-26
通过列举linux平台下的例子，并结合gdb描述了堆栈溢的过程。
gcc8之前，coredump文件无法显示正确的函数调用栈信息
安安爸Chris的专栏
10-14 968
在c++里，如果在Thread中有未捕获的异常，那么gcc会主动catch该异常，从而导致函数栈中无有用的信息。 下面是一个例子 #include <stdexcept> #include <thread> void foo() { throw std::runtime_error("foo"); } int main() { thread t(foo); t.join(); } 使用编
[gdb]函数堆栈乱掉的解决办法
weixin_33743703的博客
03-19 685
程序core掉,要去debug,但是函数堆栈乱掉了,很恶心.....经过Google/wiki一番,找到两种解决办法. 1. 手动还原backtrace 　　手动还原其实就是看栈里面的数据,自己还原函数栈,听起来很复杂其实也比较简单.手头上没有比较好的例子,所以大家就去看 　　http://devpit.org/wiki/x86ManualBacktrace 上面的例子.那个例子很好,是x8...
程序故障分析coredump
chunlovenan的专栏
05-07 1795
core dump
【栈越界】栈被破坏导致的死机
叮咚的博客
06-14 1036
在众多的coredump中，有一类crash调试起来是最麻烦的，那就是“栈被破坏”导致的函数调用回溯结构破坏引发的coredump。本文，主要讲讲这一类crash的成因、原理以及调试方法、如何还原堆栈并定位该问题
使用 GDB 恢复堆栈信息
swartz_lubel的专栏
09-13 4144
用 C/C++ 编写的程序, 如果遇到 Segmentation Fault 则可以通过生成 coredump 来进行调试, 根据记录的信息定位到出错代码行. 但很多时候可能用 gdb 打开 coredump 文件查看堆栈时, 却出现一堆问号, 无法直接定位到出错代码行. 本文介绍另一种方法来还原错乱的堆栈信息. 例如, 下图是 coredump 后用 gdb 看到的堆栈信息, 可以看到这些
3 gdb如何从堆栈破坏的堆栈中定位问题(ucontext_t)
u012906122的专栏
04-05 3580
本文介绍了在gdb堆栈破坏但有ucontext_t进程上下文信息时调试定位问题的完整过程。通过分析段错误日志和core dump，结合ucontext_t结构中的寄存器信息（包括fault_address、LR返回地址等），成功定位到X11_XUnsetICFocus接口中的指针越界问题。通过反汇编代码和寄存器分析，发现是函数指针变为野指针导致异常。最终通过加线程ID打印验证，确定是多线程环境下先析构后调用导致的访问越界问题。文章详细展示了利用ucontext_t上下文信息进行问题分析的思路和方法。
如何分析 Virtuoso 崩溃生成的 core dump 文件？
07-15
<think>我们正在解决如何分析Virtuoso崩溃产生的core dump文件的问题。根据引用[1]和[2]，core dump是程序崩溃时内存状态的记录，包含内存信息、寄存器信息等，用于调试。引用[3]则提供了Virtuoso版图数据恢复的方法，但这不是当前问题的重点。 分析core dump文件通常使用调试器（如GDB）进行。以下是具体步骤： 1. **准备环境**： - 确保有Virtuoso可执行文件和core dump文件。 - 安装GDB（GNU调试器）和调试符号（如果可用）。Cadence可能不提供公开的调试符号，但我们可以尝试分析。 2. **加载core dump**： 在终端运行： ```bash gdb /path/to/virtuoso /path/to/core ``` 例如： ```bash gdb /opt/cadence/ICADVM20/bin/virtuoso /tmp/core.virtuoso.1234 ``` 3. **查看堆栈跟踪**： 在GDB中运行： ```gdb (gdb) bt ``` 这可以显示崩溃时的函数调用堆栈。如果堆栈被破坏，可以尝试： ```gdb (gdb) bt full ``` 4. **分析具体线程**： 如果程序是多线程的，需要查看所有线程的堆栈： ```gdb (gdb) thread apply all bt ``` 5. **检查寄存器状态**： ```gdb (gdb) info registers ``` 6. **查看崩溃位置代码**： 使用`disassemble`命令查看崩溃点附近的汇编代码： ```gdb (gdb) disas /m $pc ``` 7. **检查内存**： 如果崩溃是由于访问非法地址（如空指针）： ```gdb (gdb) x/x $pc # 查看程序计数器指向的指令 (gdb) x/x $sp # 查看栈指针 ``` 8. **结合日志**： 将core dump中的信息与Virtuoso日志（`virtuoso.log`）结合分析。 **注意事项**： - 如果没有调试符号，堆栈跟踪可能只有地址，没有函数名和行号。此时需要联系Cadence技术支持，并提供core dump和日志。 - 确保分析环境与崩溃环境一致（如操作系统版本、库版本等）。 引用[3]提到的数据恢复方法（利用`layout.cd-`恢复版图）是独立的，与core dump分析无关，但可以作为数据恢复的补充手段[^3]。 §§相关问题§§ 1. 如何配置系统以在Virtuoso崩溃时生成core dump文件？ 2. 在没有调试符号的情况下，如何从core dump中获取有用的信息？ 3. Virtuoso崩溃后如何恢复未保存的版图数据？ 4. 如何向Cadence技术支持提交core dump文件？</think>### 分析 Virtuoso 崩溃生成的 core dump 文件的方法 #### 一、准备工作 1. **确保 core dump 已生成** - 在崩溃前启用 core dump： ```bash ulimit -c unlimited echo "/tmp/core.%e.%p" | sudo tee /proc/sys/kernel/core_pattern ``` - 验证生成位置： ```bash ls /tmp/core.virtuoso.* # 确认 core 文件存在 ``` 2. **准备调试环境** - 安装调试工具： ```bash sudo apt install gdb # GNU 调试器 sudo apt install binutils # 二进制工具集 ``` - 获取 Virtuoso 可执行文件路径： ```bash which virtuoso # 通常为 /opt/cadence/ICADVM*/bin/virtuoso ``` --- #### 二、核心分析步骤 1. **加载 core dump** ```bash gdb /opt/cadence/ICADVM20/bin/virtuoso /tmp/core.virtuoso.12345 ``` > 输出示例： > `Core was generated by 'virtuoso -log run.log'.` > `Program terminated with signal SIGSEGV, Segmentation fault.` 2. **查看崩溃堆栈** ```gdb (gdb) bt full # 打印完整调用堆栈 ``` **关键输出分析**： - `#0 0x00007f5a1b1c3e20 in oaTech::getVersion() const ()` → OA 库问题 - `#1 0x000055f8e2d7a1d1 in dbOpen()` → 数据库操作崩溃点 - `#2 0x000055f8e2cbbf04 in LayoutView::render()` → 图形渲染错误 3. **检查寄存器状态** ```gdb (gdb) info registers ``` 重点关注： - `$rip` (指令指针)：崩溃点的机器指令地址 - `$rsp` (栈指针)：检测栈溢出 - `$rax`/`$rdx`：函数返回值或参数寄存器 4. **反汇编崩溃点** ```gdb (gdb) disas /m $rip-8,+16 # 反汇编崩溃点前后代码 ``` 输出示例： ```asm 0x55f8e2d7a1d1 <dbOpen+123>: mov 0x20(%rsp),%rdi 0x55f8e2d7a1d6 <dbOpen+128>: callq 0x55f8e2e0a1a0 <oaTech::getVersion()> # 崩溃点 ``` 5. **检查内存映射** ```gdb (gdb) info proc mappings ``` 识别异常内存区域： - `[anon]` 段 → 堆内存问题 - `libX11.so` → 图形驱动问题 - `[stack]` → 栈溢出 --- #### 三、高级分析技巧 1. **符号解析增强** ```gdb (gdb) set debug-file-directory /opt/cadence/ICADVM20/lib (gdb) sharedlibrary # 加载所有共享库符号 ``` 2. **追踪内存访问** ```gdb (gdb) x/10xg $rsp # 检查栈顶内容 (gdb) x/s 0x7ffd1234abcd # 查看字符串内容 ``` 3. **多线程分析** ```gdb (gdb) thread apply all bt # 所有线程堆栈 (gdb) thread 2 # 切换到2号线程 ``` --- #### 四、典型崩溃场景诊断 | 崩溃特征 | 可能原因 | 验证方法 | |---------------------------|---------------------------|------------------------------| | `SIGSEGV in libX11.so` | 图形驱动冲突 | `info sharedlibrary` 检查 | | `rax=0x0 in oaTech call` | 空指针解引用 | `x/gx $rdi` 查看参数是否为空 | | `[stack] address invalid` | 栈溢出 | `info frame` 检查栈帧大小 | | `mmap failed` | 内存耗尽 | `info proc mappings` 查剩余空间 | --- #### 五、数据恢复（结合引用[3]） 若 core dump 分析无效，优先恢复设计数据： ```bash cd <library_path>/<cell_name>/layout mv layout.cdb layout.cdb_bak # 备份 cp layout.cd- layout.cdb # 使用自动保存数据 ``` > 此操作可恢复 Virtuoso 异常退出前的版图状态[^3]。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值