GDB自杀（突然杀死调试过程）

我通过GDB（版本7.12，Ubuntu 14.04）运行一个非常大的应用程序（二进制有2GB，主要是因为调试符号），所以我可以捕获所有崩溃和有完整的后退+ coredumps： ulimit -c unlimited 和bt/bt full/info thread/generate-core-file崩溃后。GDB自杀（突然杀死调试过程）

但是，我很少遇到一些奇怪的行为：应用程序在日志中立即关闭Program terminated with signal SIGKILL, Killed.，但是我是100％正面的，没有其他任何来自系统的杀死它，负责为此的GDB负责。当发生这种情况时，它不会产生任何回溯/ coredump /等。

据我看到，直到现在，这发生在大（1天）的正常运行时间。每当正常的崩溃发生在〜1天的正常运行时间（我不是在谈论杀死情况，而是正常崩溃），并且GDB生成backtrace + coredump时，核心处理器大小为〜100GB。所以现在唯一需要假设的是GDB消耗了太多的内存来处理它。不幸的是，当发生这种情况时，我不知道确切的内存使用情况（因为它是意外的），但交换文件几乎是空的，这很可能意味着它没有真正耗尽内存。

关于如何调试这种情况的想法？

来源

2017-07-06 Shocker

这可能是OOM杀手。看看'dmesg'的输出：'内存不足：杀死进程'。 – ks1322

你是对的，检查dmesg日志，我发现'ps被调用的oom-killer：gfp_mask = 0x1042d0，order = 2，oom_score_adj = 0'内存不足：杀死进程8057（MY_BINARY_NAME_HERE）得分909或牺牲子对象发生了。添加一个单独的答案，以便我可以接受它。同时，关于为什么交换将是空的任何想法？在这种情况下，我会预料它会变满。或者，它可能与同一进程的内存已满... – Shocker

二元拥有2GB

你很可能运行内存和你的应用程序可能是由OOM杀手杀害。要确认这个看dmesg输出为oom-killer和Killed process消息。

但交换文件几乎是空的，这很可能意味着它没有真正耗尽内存

这取决于PROC vm.swappiness值。尝试增加此参数以增加内核交换内存页的积极性。见man proc：

/proc/sys/vm/swappiness 
      The value in this file controls how aggressively the kernel 
      will swap memory pages. Higher values increase 
      aggressiveness, lower values decrease aggressiveness. The 
      default value is 60.

来源

2017-07-07 11:05:36 ks1322

GDB自杀（突然杀死调试过程）

回答

相关问题