[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [JunkMail] Re: RE23 testing

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/