Question

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

我还没有配置我的核心模式，因此我的进程启动目录中只能存在一个核心（名为“核心”）。我的问题下面有更多细节。

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

的.bash_profile

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

/etc/security/limuits.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

EDIT1

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

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

我的大约一半进程到达其中一行和段错误，可能在几毫秒之内，因为它们采用几乎相同的代码路径。我不是简单地提出（SIGSEGV），因为我已经看到我的程序吞下并继续之前;也许是因为技术上信号不需要退出？

EDIT2

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

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

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

Ubuntu“有时”无法生成核心文件吗？

0 个答案: