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: ru.po in bash 3.2 p1
Thanks guys, The patch works for me. On Oct 21, 2006, at 11:24 AM, Dmitry V. Levin wrote: On Sat, Oct 21, 2006 at 11:42:48AM -0400, Chet Ramey wrote: Marius Schamschula wrote: Chet, I have built bash 3.2 patchlevel 1 under Mac OS X 10.4.8 (both PPC and Intel) and I get the following error while installing: make[2]: [EMAIL PROTECTED]' is up to date. rm -f ru.gmo /usr/local/bin/msgfmt -c --statistics -o ru.gmo ru.po ru.po:21:9: invalid multibyte sequence The following patch has been reported to fix the problem (http://lists.gnu.org/archive/html/bug-bash/2006-10/msg00076.html): I confirm, the fix is correct, Cc'ed to ru.po maintainer. *** ../bash-3.2/po/ru.poTue Jan 10 17:51:03 2006 --- po/ru.poMon Oct 16 15:13:23 2006 *** *** 13,17 Language-Team: Russian [EMAIL PROTECTED]\n MIME-Version: 1.0\n ! Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=3; plural=(n%10==1 n%100!=11 ? 0 : n% 10=2 n%10=4 (n%10010 || n%100=20) ? 1 : 2);\n --- 13,17 Language-Team: Russian [EMAIL PROTECTED]\n MIME-Version: 1.0\n ! Content-Type: text/plain; charset=KOI8-R\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=3; plural=(n%10==1 n%100!=11 ? 0 : n% 10=2 n%10=4 (n%10010 || n%100=20) ? 1 : 2);\n -- ldv Marius -- Marius Schamschula, Alabama A M University, Department of Physics The Center for Hydrology Soil Climatology and Remote Sensing http://optics.physics.aamu.edu/ - http://www.physics.aamu.edu/ http://wx.aamu.edu/ - http://www.aamu.edu/hscars/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Problem with echo -e in bash 3.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Adding bug-coreutils to CC] According to Chet Ramey on 10/21/2006 11:52 AM: Jochen Roderburg wrote: I finally tracked this down to a changed behaviour of the builtin echo command. Namely, the formecho -e '\nnn' with a 3-digit octal number does not work any longer, only the variant echo -e '\0nnn' with a leading zero. Don't know it this is a bug or feature ;-) It's intentional. The xpg_echo and `echo -e' code should be identical, and the xpg_echo code is required by POSIX/XSI to interpret octal constants only with the leading `0'. There are lots of ways to indicate that backslash escapes should be interpreted -- maybe too many -- but when they are, they should behave consistently. The 'program' echo from current GNU coreutils interprets the \nnn form (correctly?). I don't think the coreutils echo wants echo -e to be POSIX-conformant the way bash is (it's an implementation choice -- POSIX doesn't specify echo -e). It looks like it is time for coreutils to revisit how /bin/echo should behave, with or without the presence of POSIXLY_CORRECT. It would be good for coreutils 6.4 to match bash 3.2 in what escape sequences it understands. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFOnd784KuGfSFAYARAoLdAKC4J8DeOj8uM3lZdIYVs49eKj6IowCeJCha zTvb+RYcQNONY04YvE9Fhf8= =NhIR -END PGP SIGNATURE- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
