Question

我正在设置

ulimit -c unlimited.

在c ++程序中我们正在做

struct rlimit corelimit;
  if (getrlimit(RLIMIT_CORE, &corelimit) != 0) {
    return -1;
  }
  corelimit.rlim_cur = RLIM_INFINITY;
  corelimit.rlim_max = RLIM_INFINITY;
  if (setrlimit(RLIMIT_CORE, &corelimit) != 0) {
    return -1;
  }

但是每当程序崩溃时，它生成的核心转储就会被截断。

BFD: Warning: /mnt/coredump/core.6685.1325912972 is truncated: expected core file size >= 1136525312, found: 638976.

可能是什么问题？

我们正在使用Ubuntu 10.04.3 LTS

Linux ip-<ip> 2.6.32-318-ec2 #38-Ubuntu SMP Thu Sep 1 18:09:30 UTC 2011 x86_64 GNU/Linux

这是我的/etc/security/limits.conf

# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#<domain>        <type>  <item>  <value>
#
#Where:
#<domain> can be:
#        - an user name
#        - a group name, with @group syntax
#        - the wildcard *, for default entry
#        - the wildcard %, can be also used with %group syntax,
#                 for maxlogin limit
#        - NOTE: group and wildcard limits are not applied to root.
#          To apply a limit to the root user, <domain> must be
#          the literal username root.
#
#<type> can have the two values:
#        - "soft" for enforcing the soft limits
#        - "hard" for enforcing hard limits
#
#<item> can be one of the following:
#        - core - limits the core file size (KB)
#        - data - max data size (KB)
#        - fsize - maximum filesize (KB)
#        - memlock - max locked-in-memory address space (KB)
#        - nofile - max number of open files
#        - rss - max resident set size (KB)
#        - stack - max stack size (KB)
#        - cpu - max CPU time (MIN)
#        - nproc - max number of processes
#        - as - address space limit (KB)
#        - maxlogins - max number of logins for this user
#        - maxsyslogins - max number of logins on the system
#        - priority - the priority to run user process with
#        - locks - max number of file locks the user can hold
#        - sigpending - max number of pending signals
#        - msgqueue - max memory used by POSIX message queues (bytes)
#        - nice - max nice priority allowed to raise to values: [-20, 19]
#        - rtprio - max realtime priority
#        - chroot - change root to directory (Debian-specific)
#
#<domain>      <type>  <item>         <value>
#

#*               soft    core            0
#root            hard    core            100000
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#    ftp             -       chroot          /ftp
#@student        -       maxlogins       4



#for all users
* hard nofile 16384
* soft nofile 9000

更多详情

我正在使用gcc优化标志

O3

我将堆栈线程大小设置为.5 mb。

Answer 1

我记得管理员可以设置一个硬限制，以及用户设置的软限制。如果软限制强于硬限制，则采用硬限制值。我不确定这对任何shell都有效，我只能从bash中知道它。

Answer 2

我遇到了同样被截断的核心文件的问题。

进一步调查显示ulimit -f（又名file size，RLIMIT_FSIZE）也会影响核心文件，因此请检查限制是否也无限制/适当高。 [我在Linux内核3.2.0 / debian wheezy上看到了这一点。]

Answer 3

如果您使用的是Intent intent = new Intent(Intent.ACTION_GET_CONTENT); intent.setType("audio/*"); intent.setFlags(Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT); startActivityForResult(intent, CODE_CHOOSE_FILE);，则可能的解决方案是编辑coredumpctl并增加/etc/systemd/coredump.conf和ProcessSizeMax：

ExternalSizeMax

Answer 4

硬限制和软限制对它们有一些细节可能有点毛茸茸：请参阅this关于使用sysctl命名最后的更改。

有一个file可以编辑，应该使限制大小持续，尽管可能会有相应的sysctl命令...

Answer 5

当我用kill -3手动杀死程序时发生了类似的问题。这只是因为我没有等待核心文件完成生成的时间。

确保文件大小停止增长，然后才打开它。

Answer 6

使用自动错误报告工具（ abrt ）时，此解决方案有效。

尝试了所有建议的内容后（无济于事），我在 /etc/abrt/abrt.conf

中找到了另外一个设置，该设置会影响转储大小。

MaxCrashReportsSize = 5000

并增加了其价值。

然后重新启动abrt守护程序sudo service abrtd restart，重新运行崩溃的应用程序并获得完整的核心转储文件。

Coredump被截断了

6 个答案: