On Tue, 21 Sep 2010 13:46:30 -0500 Clayton Keller <inetad...@ruraltel.net> wrote:
> On 9/21/2010 1:37 PM, Chuck Swiger wrote: > > Hi-- > > > > On Sep 21, 2010, at 11:09 AM, Török Edwin wrote: > > [ ... ] > >> If it shows ~120M your OS is buggy. > >> Then run again with ulimit -d 2097151, and see if it reports any > >> higher value. > > > > Interesting; even on FreeBSD I get: > > > > % ./a.out > > failed after 15529 mmap() calls, allocated 2426 MB memory > > [1] 1500 abort ./a.out > > > > A bit of experimentation suggests that FreeBSD's mmap() pays > > attention to ulimit on VM size, not data segment size: > > > > % ulimit -v 256000 > > % ./a.out > > failed after 1591 mmap() calls, allocated 248 MB memory > > [1] 1544 abort ./a.out > > > > % uname -a > > FreeBSD example.com 6.4-STABLE FreeBSD 6.4-STABLE #0: Mon Sep 20 > > 16:03:45 EDT 2010 > > r...@example.com:/usr/obj/usr/src/sys/GENERIC i386 % ulimit -Ha > > -t: cpu time (seconds) unlimited -f: file size > > (blocks) unlimited -d: data seg size (kbytes) 524288 > > -s: stack size (kbytes) 65536 > > -c: core file size (blocks) unlimited > > -m: resident set size (kbytes) unlimited > > -l: locked-in-memory size (kb) unlimited > > -u: processes 3603 > > -n: file descriptors 7207 > > -N 9: socket buffer size (kb) unlimited > > -v: virtual memory size (kb) unlimited > > > > Regards, > > Here are my findings on a 32-bit CentOS 5.5 system: > > # cat /etc/redhat-release > CentOS release 5.5 (Final) > > Here are my results without any ulimit -d modifications: > > # ulimit -a > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 8192 > max locked memory (kbytes, -l) 32 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 10240 > cpu time (seconds, -t) unlimited > max user processes (-u) unlimited > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > # ./a.out > failed after 19648 mmap() calls, allocated 3070 MB memory > Aborted > > > And now with the requested ulimit -d change: > > # ulimit -d 2091751 > > # ulimit -a > core file size (blocks, -c) 0 > data seg size (kbytes, -d) 2091751 > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 8192 > max locked memory (kbytes, -l) 32 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 10240 > cpu time (seconds, -t) unlimited > max user processes (-u) unlimited > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > # ./a.out > failed after 19649 mmap() calls, allocated 3070 MB memory > Aborted > > So there looks to be no change on this platform. Yes, you can ignore it. I'll add #ifdef C_BSD to that warning for 0.96.4. Best regards, --Edwin _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
