【问题标题】:Is it possible to remove the heap from an ELF Core file?是否可以从 ELF 核心文件中删除堆?
【发布时间】:2015-01-19 23:52:45
【问题描述】:

我正在通过/proc/sys/kernel/core_pattern 从非常大的核心转储中收集堆栈跟踪。以下问题建议使用/proc/pid/core_filter 来减小大型核心转储的大小:

Minimal core dump (stack trace + current frame only)

Selective core dump in Linux - How can I select the dumped sections?

Is it possible to get a Linux coredump that only contains callstack, threads, and local variables?

但是,当将 core_filter 设置为 '0' 时,生成的 coredump 对 gdb 的 bt 命令不再有意义。

所以,我有以下两部分的问题:

1) 除了 gdb 之外,还有什么工具可以从这些最小的核心转储中提取堆栈跟踪吗?

2) 是否可以解析 ELF Core 文件以删除堆段?这个问题:What and where are the stack and heap? 似乎表明这是可能的。

谢谢!

【问题讨论】:

  • 做到这一点应该不难。获取 ELF 规范,在一些现有的核心转储文件上使用 readelf,看看您是否可以选择性地复制一个省略您不关心的程序段的文件。
  • @KerrekSB 听起来不错 - 但是,我如何识别我不关心的细分?
  • 好吧,程序头告诉你虚拟地址和段的大小......有帮助吗?
  • @KerrekSB hmmm...定位段和段的虚拟地址范围不是问题。我的问题是,我怎么知道哪些段包含堆数据,哪些包含堆栈数据?希望能澄清事情。谢谢!
  • 在我的 64 位系统上,堆段似乎从“0x00007f2xxxxxxxxx”开始,堆栈在“0x00007fffxxxxxxxx”——寻找可读写的页面。

标签: c++ linux-kernel operating-system stack-trace elf


【解决方案1】:

但是,当将 core_filter 设置为 '0' 时,生成的 coredump 对 gdb 的 bt 命令不再有意义。

请注意,对于动态链接的二进制文件,GDB backtrace 需要了解堆栈跟踪中出现的所有共享库(因此它可以找到相应的展开描述符)。

对于“普通”核心文件,此信息位于 中。从core 删除堆然后损坏info shared,这反过来又使具有任何共享库的backtrace 无法工作。

您可以关闭位 0 和 1(匿名私有和共享映射,这将覆盖堆)并且仍然获得可用的核心 如果您打开位 3(这将覆盖文本共享库,通常不是必需的,但通过丢弃堆是必需的)。

【讨论】:

  • 感谢您的信息!我尝试将 core_filter 设置为 24 (0x18),但 gdb bt 仍然无法使用核心。不过,额外的见解很有帮助。
  • 我找到了这篇论文:researchgate.net/publication/…,它只保留了堆栈的程序段。我怀疑这是否适用于 x86_64 —— 你怎么看?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-05-29
  • 2012-03-24
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多