Donn Cave wrote:
On Feb 14, 2008, at 2:32 AM, Howard Chu wrote:
Donn Cave wrote:
On NetBSD 3.1, test008-concurrency dies trying to allocate
8388608 bytes -
search_candidates: base="dc=example,dc=com" (0x00000001) scope=2
ch_malloc of 8388608 bytes failed
assertion "0" failed: file "ch_malloc.c", line 57, function
"ch_malloc"
Also, same failure with test039-glue-ldap-concurrency - could
be a pattern here.
Yes, both tests would have similar behavior. It seems to me that
this isn't anything unusual though. Does NetBSD default to a
particular ulimit on datasize?
$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) 131072
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 1279544
max memory size (kbytes, -m) 3838632
open files (-n) 64
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 2048
cpu time (seconds, -t) unlimited
max user processes (-u) 160
virtual memory (kbytes, -v) 133120
The tests complete OK on 2_3 and 2_4, with data seg up to 1048576,
max memory size unlimited, stack size 32768, virtual memory 1081344.
Sounds ok. I also seem to recall test036 or test039 having problems on some
Unix systems (AIX or HPUX IIRC) if the number of files wasn't at least 128 or
so. (Since Linux defaults to 1024 this problem never came up there.) You
shouldn't need to alter the stack limit; that only applies to the initial
program stack and slapd does all its work in threads which each get their own
explicitly allocated stack.
The pipe size is surprising, usually it's 1 page (4096 bytes). I guess that
won't have any impact here though.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
