Coredump усекается

Question

Coredump усекается

Я устанавливаю

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,

25

c++ linux gdb coredump

Источник

user428705 07 янв '12 в 09:38

4 ответа

Другие вопросы по тегам c++ linux gdb coredump

user293878 16 янв '20 в 10:08 2020-01-16 10:08 · Answer 1 · 2020-01-16 10:08

Если вы используете coredumpctl, возможное решение - отредактировать /etc/systemd/coredump.conf и увеличить ProcessSizeMax а также ExternalSizeMax:

[Coredump]
#Storage=external
#Compress=yes
ProcessSizeMax=20G
ExternalSizeMax=20G
#JournalSizeMax=767M
#MaxUse=
#KeepFree=

6

Источник

user293878 16 янв '20 в 10:08

user1187776 16 апр '12 в 13:05 2012-04-16 13:05 · Answer 2 · 2012-04-16 13:05

Я помню, что существует жесткий предел, который может быть установлен администратором, и мягкий предел, который устанавливается пользователем. Если мягкий предел превышает жесткий предел, принимается значение жесткого ограничения. Я не уверен, что это справедливо для любой оболочки, я знаю это только из bash.

user292166 10 июл '14 в 16:14 2014-07-10 16:14 · Answer 3 · 2014-07-10 16:14

У меня была такая же проблема с усечением основных файлов.

Дальнейшее расследование показало, что ulimit -f (ака file size, RLIMIT_FSIZE) также влияет на основные файлы, поэтому убедитесь, что лимит также неограничен / достаточно высок. [Я видел это в ядре Linux 3.2.0 / debian wheezy.]

3

Источник

user292166 10 июл '14 в 16:14

user1337526 30 апр '12 в 13:54 2012-04-30 13:54 · Answer 4 · 2012-04-30 13:54

Жесткие лимиты и мягкие лимиты имеют некоторые особенности, которые могут быть немного сложными: посмотрите, как использовать sysctl, чтобы сделать изменения в последний раз.

Существует файл, который вы можете отредактировать, и он должен ограничивать размер последнего, хотя, вероятно, есть соответствующая команда sysctl, которая сделает это...

user1806511 28 дек '14 в 11:45 2014-12-28 11:45 · Answer 5 · 2014-12-28 11:45

Подобная проблема произошла, когда я убил программу вручную с помощью kill -3. Это произошло просто потому, что я не дождался достаточного времени для генерации файла ядра.

Убедитесь, что файл перестал увеличиваться в размере, и только затем откройте его.

0

Источник

user1806511 28 дек '14 в 11:45

user9027283 10 фев '20 в 12:47 2020-02-10 12:47 · Answer 6 · 2020-02-10 12:47

Это решение работает, когда используется инструмент автоматического сообщения об ошибках (abrt).

После того, как я попробовал все, что уже предлагалось (ничего не помогло), я нашел еще один параметр, который влияет на размер дампа, в /etc/abrt/abrt.conf

MaxCrashReportsSize = 5000

и увеличил его стоимость.

Затем перезапустили демон abrt: sudo service abrtd restart, повторно запустил аварийное приложение и получил полный файл дампа ядра.