【问题标题】:Application crashes, but no core dump generated应用程序崩溃,但未生成核心转储
【发布时间】:2012-12-30 11:15:05
【问题描述】:

我有一个问题,我的应用程序在几天/几周后继续转储核心,但不幸的是,没有生成核心转储。

我们尝试设置ulimit -c unlimited 没有成功,因此我们在代码本身中加入了setrlimit 功能,但这种方法也没有运气。而且,除此之外,我们还添加了 MALLOC_CHECK_。

有趣的是,当我们尝试启动手动核心转储(使用kill -ABRT <pid>)时,它确实生成了核心转储。

我可以在/var/log/message看到以下消息

内核:[2302077.396021] myapp[22140]:段错误在 54552e42 ip 00000000f773f36f sp 00000000fffdc48c 错误 4 in ld-2.11.3.so[f7727000+1f000]

环境:sles11

有关如何使应用程序更可靠地生成核心转储的任何建议?

【问题讨论】:

  • 使用选项-Wall -g 编译您的代码。修复它,直到不再发出警告。在开始之前,从 shell 调用 ulimit -c unlimited。致电ulimit -a 了解详情。
  • 不将内核写入磁盘的明显原因是磁盘空间不足。另一个是该目录不存在。至于崩溃的原因,我猜是某种资源泄漏。最常见的资源泄漏是内存泄漏和文件句柄韭菜。
  • @alk,我们用 -g 标志编译了代码。我们也尝试了 ulimit -c unlimited ,但没有运气。在我们尝试了所有这些事情之后,我们才转向 setrlimit 方法。
  • @KlasLindbäck 我们可以使用 kill -ABRT 生成核心,所以我希望环境不应该成为问题。
  • 您已验证该进程可以创建核心。这很好,因为这意味着你可以勾勒出许多你没有得到的原因。我能想到的唯一另一件事是杀死进程的信号是不会创建核心转储的信号。我在这里找到了 Mac OS/X 的列表:manpagez.com/man/2/sigaction。我的 google karma 没有找到适用于 Linux 的,但也许你的 karma 更好(或者至少你有动力花更多时间找到一个)。

标签: c linux gdb opensuse suse


【解决方案1】:

许多当前系统都经过配置,因此它们不会留下核心转储(普通用户不知道如何处理它们)。

  • 确保启动可以转储核心的进程(可写目录,足够的空间;我不确定进程中的目录更改是否会干扰这里)
  • 确保在启动进程的同一 shell 中提供“ulimit -c unlimited”
  • 如果程序是 SUID 或 SGID,出于安全原因,内核将拒绝使其转储内核,请查看this question 以获得指导

【讨论】:

  • 还值得检查文件 /proc/sys/kernal/core_pattern 以查看核心文件的放置位置。 /etc/sysctl.conf 有一个类似的,但可以更永久地设置。
【解决方案2】:

我刚刚在使用 SLES 11 时遇到了同样的问题。除了给出的建议,特别是设置“ulimit -c unlimited”,您还需要做一些事情:

  1. 修改 /etc/security/limits.conf 以添加以下行。然后注销并重新登录以确保安全。

    *               soft    core            unlimited
    
  2. 默认内核核心模式是“/var/log/cores/%e/%p-%s-%t.core”。 (参见 core(5)。)如果目录部分不存在,Linux 将不会创建核心文件。因此,您需要创建“%e”位,这是您的二进制文件的名称,或者您可以更改模式。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-04-12
    • 1970-01-01
    • 1970-01-01
    • 2017-03-26
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多