1

我已经配置了一个 Amazon EC2 实例以在进程崩溃时生成核心文件，并且在大多数情况下它按预期工作。问题是它并不总是有效。我遇到问题的程序由 9 个通过 MPI 协同工作的并发进程组成。当这个程序崩溃时，我几乎总是得到一个核心转储，但在极少数情况下没有生成核心转储，即使在我的捕获 stdErr 的日志中报告了 segfault(11)。在其他情况下（非常罕见），生成的核心文件会被截断。

我没有配置我的核心模式，所以只有一个核心（名为“核心”）可以存在于我的进程启动的目录中。我的问题下方有更多详细信息。

“有时”如何不生成核心转储？是否有可能两个进程试图同时转储一个核心文件，并且都因为冲突而失败？核心转储不是跟踪错误的可靠方法吗？

.bash_profile

export LD_LIBRARY_PATH=/usr/local/lib
source ./.bashrc
ulimit -c unlimited

/etc/security/limits.conf

*                soft    core            unlimited
root             hard    core            unlimited

ulimit -a

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 29879
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 29879
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

编辑1

我发现了一个可以可靠地省略核心文件的错误。为了在程序处于可疑状态时生成内核，我在几个地方插入了以下几行：

if (value > FLT_MAX){
    int *i=NULL;
    *i=1;
}

大约一半的进程到达这些行和段错误中的一条，可能在几毫秒之内，因为它们采用几乎相同的代码路径。我不只是 raise(SIGSEGV) 因为我已经看到我的程序吞下了它并在之前继续；也许是因为信号在技术上不需要退出？

编辑2

核心文件现在在其名称中包含 pid：

sudo -s
echo "1" > /proc/sys/kernel/core_uses_pid

问题仍然存在。在某些情况下，ubuntu 中是否存在阻止它一次写入多个核心文件的限制？

4

0 回答 0