【问题标题】:Find which program caused a core dump file查找导致核心转储文件的程序
【发布时间】:2012-11-09 13:23:37
【问题描述】:

我最近一直在进行密集的程序/包安装,所以我无法确定是哪个新安装的程序(或旧程序)导致在我的主文件夹中出现 core 文件。这是一台服务器,所以我最好找出机器上任何可能的不稳定来源。

【问题讨论】:

  • 在 FreeBSD 上这对我有用,dmesg | tail -n 20
  • @SIFE 如果它发生在最近,它肯定有效。

标签: linux debugging ubuntu coredump


【解决方案1】:

您可以简单地使用file 程序来识别它们:

例如

# file /var/core/core
/var/core/core:     ELF 64-bit MSB core file SPARCV9 Version 1, from 'crs_stat.bin'

【讨论】:

  • 有时我有一些核心文件,无论出于何种原因,“文件”都无法识别——在这种情况下,核心文件中字符串输出的最后一行通常包含可执行文件的路径能够帮助。例如"strings /path/to/corefile | tail -n 1" 经常有效,或者看最后几行。
  • @jsegal:很好的发现,但是当find 告诉我时我需要strings core | grep ^/ | tail -1too many program header sections
  • 我不确定我是否理解,ELF 64 位不知道哪个二进制文件生成了核心转储?
【解决方案2】:

经常在核心文件上使用文件程序会显示错误的可执行文件,正如@Benj 在接受的答案(Benj 的答案中的代码)中所解释的那样:

# file /var/core/core
/var/core/core:     ELF 64-bit MSB core file SPARCV9 Version 1, from 'crs_stat.bin'

但是,有时您可能会收到关于“程序头部分过多”的投诉:

core.some-lib.nnnn.nnnn: ELF 64-bit LSB  core file x86-64, version 1 (SYSV), too many program header sections (1850)

在这种情况下,您可以尝试一些替代方案:

  • 跟踪核心文件的最后几个字符串(该应用程序对我来说大约是 25 个):strings core.some-lib.nnnn.nnnn | tail -50
  • 使用 gdb 本身:gdb -c core.some-lib.nnnn.nnnn 这通常会告诉你这样的事情:Core was generated by '/usr/local/bin/some-executable'

【讨论】:

    【解决方案3】:

    您可以导航到 core.pid 所在的目录并运行 gdb core core.pid

    【讨论】:

      猜你喜欢
      • 2015-10-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2023-04-06
      • 1970-01-01
      • 1970-01-01
      • 2023-03-14
      相关资源
      最近更新 更多