【问题标题】:Difference between core and core-file核心和核心文件之间的区别
【发布时间】:2014-04-06 11:28:39
【问题描述】:

这是在 Ubuntu 12.04 上,GDB 版本 GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04

我处理的应用程序转储核心的次数比我关心的要多。当我按如下方式启动 gdb 时,我没有得到任何可用的回溯。

gdb --core <path to core dump>

GDB 确实显示了导致核心转储的进程的完整路径以及命令行参数。

在 gdb 提示符下,如果我执行命令

file <path to executable>
core-file <path to core dump>

我确实得到了可用的回溯。

--core 命令行选项和从 gdb 提示符执行的 core-file 命令有什么区别。

无论如何我可以在命令行中执行此操作。毕竟,gdb 确实知道可执行文件的路径和核心文件名。

【问题讨论】:

  • 你能做到gdb pathtoexecutable --core pathtocore 吗?
  • @Mark:我当然可以。我的主要兴趣是为什么 gdb 的行为不同。它当然有进程路径,为什么它不从进程中加载​​符号。

标签: linux ubuntu gdb core


【解决方案1】:

无论如何我可以在命令行中执行此操作。

是的:gdb /path/to/exe /path/to/core

我的主要兴趣是为什么 gdb 行为不同。

没有。

大多数 UNIX 系统为了节省磁盘空间,不会将文件支持的只读页面(例如程序代码)转储到核心文件中——该代码已经在磁盘上,为什么还要重新编写呢? (这实际上是可配置的:参见man corecoredump_filter)。

但是这些只读页面包含符号(你在nmbacktrace 输出中看到的),所以如果你不告诉GDB 可执行文件在哪里,那么它就不能产生有意义的@ 987654326@.

毕竟,gdb 确实知道可执行文件的路径

不,它没有。

内核记录了关于生成内核的可执行文件的不完整信息。该信息不可靠:

  • 它可以记录相对路径,例如./a.out 并且绝对不能保证您的当前目录在 GDB 分析时与调用可执行文件时的目录相同,并且
  • elf_prpsinfo.pr_fname[] 中只有 16 个字符的空格,超过此长度的任何内容都将被截断。

【讨论】:

  • 感谢您的信息。现在有些事情更清楚了。我很困惑,因为在我的特定情况下,我总是看到 gdb 打印完整路径。我只是最终将文件命令的路径复制到 gdb。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-10-03
  • 2018-09-04
  • 2014-10-17
  • 1970-01-01
  • 2020-06-06
  • 2019-11-13
  • 2018-01-06
相关资源
最近更新 更多