ulimit -c for core dumps
Hi,
I'm trying to limit the size of coredumps using 'ulimit -c'. Can
someone please explain why a core file gets generated from the coretest
program (source is below)?
Thanks for any help or suggestions.
Shell interaction
% ulimit -H -c
unlimited
% ulimit -S -c
0
% bash --version
GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.
% ulimit -c 512
% ulimit -S -c
512
% ulimit -H -c
512
% ./coretest 2048
rlim_cur,rlim_max = 524288,524288
malloced 2097152 bytes my pid is 21255
Segmentation fault (core dumped)
% ls -l core
-rw--- 1 jacr swdvt 2265088 2006-10-19 14:24 core
%
#include
#include
#include
#include
#include
#include
int main(int argc, char* argv[])
{
char* c;
int mult=1024;
int sz;
struct rlimit rlim;
if(getrlimit(RLIMIT_CORE,&rlim))
printf("error getting rlimit\n");
printf("rlim_cur,rlim_max = %u,%u\n",rlim.rlim_cur,rlim.rlim_max);
if(argc>1)
mult=atoi(argv[1]);
sz=mult*1024;
c=malloc(sz);
if(!c)
{
printf("unable to malloc\n");
exit(EXIT_FAILURE);
}
printf("malloced %u bytes my pid is %u\n",sz,getpid());
raise(SIGSEGV);
return EXIT_SUCCESS;
}
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
need explanation ulimit -c for limiting core dumps
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-pc-linux-gnu'
-DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include
-I../bash/lib -g -O2
uname output: Linux galaxy2 2.6.12.4 #2 SMP Tue Oct 17 14:53:07 EDT 2006 i686
GNU/Linux
Machine Type: i386-pc-linux-gnu
Bash Version: 2.05b
Patch Level: 0
Release Status: release
Description:
Hi,
I'm trying to limit the size of coredumps using 'ulimit -c'. Can someone
please explain why a core file gets generated from the coretest program (source
is below)?
Thanks for any help or suggestions.
Shell interaction
% ulimit -H -c
unlimited
% ulimit -S -c
0
% bash --version
GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.
% ulimit -c 512
% ulimit -S -c
512
% ulimit -H -c
512
% ./coretest 2048
rlim_cur,rlim_max = 524288,524288
malloced 2097152 bytes my pid is 21255
Segmentation fault (core dumped)
% ls -l core
-rw--- 1 jacr swdvt 2265088 2006-10-19 14:24 core
%
#include
#include
#include
#include
#include
#include
int main(int argc, char* argv[])
{
char* c;
int mult=1024;
int sz;
struct rlimit rlim;
if(getrlimit(RLIMIT_CORE,&rlim))
printf("error getting rlimit\n");
printf("rlim_cur,rlim_max = %u,%u\n",rlim.rlim_cur,rlim.rlim_max);
if(argc>1)
mult=atoi(argv[1]);
sz=mult*1024;
c=malloc(sz);
if(!c)
{
printf("unable to malloc\n");
exit(EXIT_FAILURE);
}
printf("malloced %u bytes my pid is %u\n",sz,getpid());
raise(SIGSEGV);
return EXIT_SUCCESS;
}
Repeat-By:
see above
Fix:
[Description of how to fix the problem. If you don't know a
fix for the problem, don't include this section.]
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: need explanation ulimit -c for limiting core dumps
Mike Stroyan wrote: I'm trying to limit the size of coredumps using 'ulimit -c'. Can someone please explain why a core file gets generated from the coretest program (source is below)? Thanks for any help or suggestions. Shell interaction % ulimit -H -c unlimited % ulimit -S -c 0 % bash --version GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu) Copyright (C) 2002 Free Software Foundation, Inc. % ulimit -c 512 % ulimit -S -c 512 % ulimit -H -c 512 % ./coretest 2048 rlim_cur,rlim_max = 524288,524288 malloced 2097152 bytes my pid is 21255 Segmentation fault (core dumped) % ls -l core -rw--- 1 jacr swdvt 2265088 2006-10-19 14:24 core Jason, This clearly is not a bash bug as your own program shows that getrlimit reports the correct setting of 512K for RLIMIT_CORE. This is a kernel surprise. The RLIMIT_CORE setting does not actually limit the size of a core file as reported by "ls -l". It limits the size of the core file on disk as reported by "du --si core". Your coretest program used a large malloc and did not actually touch the pages for that malloc. So the core dump created a sparse file with gaps at the pages that were never touched. If you change "c=malloc(sz);" to "c=calloc(sz,1);" then you will see a core file that is not sparse at all. It will be reported as 512K bytes by both ls and du. The RLIMIT_CORE effect for non-zero limits is to truncate large core files rather than prevent a core dump from happening. Sparse core files can cause trouble for the unwary. They may become non-sparse when copied. That takes up more disk space. Hi Mike, Thanks for the explanation and suggestions regarding calloc() and 'du'. That clears things up for me. I was previously not familiar with "sparse" files. I've now modified the test program source and now I see the core file getting truncated as I originally expected. Thanks again, -Jason ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: need explanation ulimit -c for limiting core dumps
Chet Ramey wrote: Matthew Woehlke wrote: Chet Ramey wrote: [EMAIL PROTECTED] wrote: I'm trying to limit the size of coredumps using 'ulimit -c'. Can someone please explain why a core file gets generated from the coretest program (source is below)? Thanks for any help or suggestions. % ulimit -H -c 512 % ./coretest 2048 rlim_cur,rlim_max = 524288,524288 malloced 2097152 bytes my pid is 21255 Segmentation fault (core dumped) % ls -l core -rw--- 1 jacr swdvt 2265088 2006-10-19 14:24 core Are you sure that's not an old core file? My Linux testing indicates that the coredump bit is set in the exit status, but no core file is actually created: $ ulimit -c 512 $ ./xcore 2048 rlim_cur,rlim_max = 524288,524288 malloced 2097152 bytes my pid is 7661 Segmentation fault (core dumped) $ ls -ls core /bin/ls: core: No such file or directory You sure your Linux makes 'core' and not 'core.', right? You might want to do 'ls -ls core*' instead... You are correct. Man, I'm having a bad day. The sparse core file has fewer blocks than the limit, though, so it's not truncated. Chet Thanks for the help folks. Not sure if you knew this or not, but at least on my linux boxen you can use '# sysctl kernel.core_pattern' to see where core files will be created and their name. I guess it's typically kernel.core_pattern = core, but sometimes you'll find kernel.core_pattern = core.%p to add the PID on the end of the name. Jason ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
