Re: need explanation ulimit -c for limiting core dumps

2006-10-21 Thread Jason Roscoe

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

2006-10-20 Thread Mike Stroyan

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.

--
Mike Stroyan
[EMAIL PROTECTED]


___
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

2006-10-20 Thread Chet Ramey
[EMAIL PROTECTED] wrote:

 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

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
$ ulimit -H -c
512
$ ulimit -S -c
512
$ ls -ls core
/bin/ls: core: No such file or directory
$ ./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

I get the same results with bash-2.05b and bash-3.2.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
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

2006-10-20 Thread Chet Ramey
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.pid', 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

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash