Я устанавливаю
ulimit -c unlimited.
И в С++-программе мы делаем
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.
Я помню, что существует жесткий предел, который может быть установлен администратором, и мягкий предел, заданный пользователем. Если мягкий предел сильнее жесткого предела, выполняется жесткое предельное значение. Я не уверен, что это действительно для любой оболочки, но я знаю это только из bash.
У меня была такая же проблема с усечением основных файлов.
Дальнейшие исследования показали, что ulimit -f (aka file size, RLIMIT_FSIZE) также влияет на основные файлы, поэтому проверьте, что ограничение также неограниченно/соответственно велико. [Я видел это на ядре Linux 3.2.0/debian wheezy.]
Жесткие ограничения и мягкие лимиты имеют некоторые особенности для них, которые могут быть немного волосатыми: см. this об использовании sysctl, чтобы сделать имя последним.
Существует файл, который вы можете редактировать, чтобы последние были лимитированы, хотя, вероятно, будет соответствующая команда sysctl, которая сделает это...
Аналогичная проблема возникла, когда я убил программу вручную с помощью kill -3. Это произошло просто потому, что я не дождался достаточного времени для завершения создания основного файла.
Убедитесь, что файл перестает расти по размеру, и только затем его можно открыть.