2012-01-07 9 views
14

io pongoCoredump è sempre troncato

ulimit -c unlimited. 

E nel programma C++ che stiamo facendo

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

ma ogni volta che il programma è sempre caduto il core dump da esso generato è sempre troncato.

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

Quale può essere il problema?

Stiamo usando 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 

Questo è il mio /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 

Maggiori dettagli

sto usando gcc flag di ottimizzazione

O3 

Sto impostando le dimensioni della filettatura dello stack su .5 mb.

+3

Hai verificato di avere spazio libero nella partizione in cui/mnt/coredump è? – ugoren

+0

sì. 32 GB è lo spazio libero. –

+0

Che dimensioni è il file principale generato? – SoapBox

risposta

3

Ricordo che esiste un limite fisso che può essere impostato dall'amministratore e un limite flessibile impostato dall'utente. Se il limite morbido è più forte del limite rigido, viene preso il valore limite rigido. Non sono sicuro che sia valido per qualsiasi shell, lo so solo da bash.

+0

Questo è corretto ... –

+3

Forse dovresti approfondire come controllare il limite rigido? –

1

I limiti rigidi e i limiti flessibili hanno alcuni aspetti specifici che possono essere un po 'pelosi: vedere this sull'utilizzo di sysctl per rendere definitive le modifiche.

C'è un file è possibile modificare che dovrebbe rendere il limite di dimensioni scorso, anche se non v'è probabilmente un corrispondente comando sysctl che farà in modo ...

2

ho avuto lo stesso problema con i file core sempre troncato.

Ulteriori indagini hanno dimostrato che ulimit -f (alias file size, RLIMIT_FSIZE) influisce anche sui file principali, quindi verificare che il limite sia anche illimitato/opportunamente alto. [L'ho visto su Linux kernel 3.2.0/debian wheezy.]

0

Un problema simile è accaduto quando ho ucciso il programma manualmente con kill -3. È successo semplicemente perché non ho aspettato abbastanza tempo perché il file core finisse di generare.

Assicurarsi che il file abbia smesso di crescere di dimensioni e solo dopo aprirlo.