Coredump quedan truncados

Question

me he fijado

ulimit -c unlimited. 

Y en C++ programa que estamos haciendo

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; 
    } 

pero cada vez que el programa se está estrelló el vaciado de memoria generada por ella quedan truncados.

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

¿Cuál puede ser el problema?

Estamos utilizando 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 

Este es mi /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 

Más detalles

que estoy usando la bandera de optimización de gcc

O3 

Estoy configurando el tamaño del hilo de la pila en .5 mb.

Answer 1

Recuerdo que hay un límite estricto que puede ser establecido por el administrador, y un límite suave establecido por el usuario. Si el límite suave es más fuerte que el límite rígido, se toma el valor límite límite. No estoy seguro si esto es válido para cualquier caparazón, solo lo sé de Bash.

Answer 2

Los límites duros y los límites flexibles tienen algunos detalles que pueden ser un poco velludos: ver this sobre el uso de sysctl para poner nombre a los cambios.

Hay una file puede editar que debe hacer el límite de tamaño de pasada, aunque es probable que haya un comando sysctl correspondiente que lo hará ...

Answer 3

que tenía el mismo problema con los archivos de núcleo quedan truncados.

Investigaciones posteriores mostraron que ulimit -f (aka file size, RLIMIT_FSIZE) afecta también archivos del núcleo, a fin de comprobar que límite también es ilimitado/adecuadamente alta. [Lo vi en Linux kernel 3.2.0/debian wheezy.]

Answer 4

Problema similar sucedió cuando destruí el programa manualmente con kill -3. Sucedió simplemente porque no esperé suficiente tiempo para que el archivo de núcleo terminara de generar.

Asegúrate de que el archivo deja de crecer en tamaño, y solo luego ábrelo.