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.