...

slapcat -f slapd.conf

So you understand that without the -l flag to slapcat, you are writing to stdout instead of a file? Is it possible that is what is causing slapcat to crash?

I used slapcat without -l for two reasons:

usually i slapcat pipiing in gzip the stdout so i can realtime gzip the ldif:

slapcat -f slapd.conf | gzip > out.ldif.gz

and also because on 32 bit slapcat, avoid the 2GB filsize limit on output ldif

...

slapcat -f slapd.conf

here the full command was:

slapcat -f slapd.conf > fulldump.ldif

However, I've retry with "-l file" on 32 bit linux and solaris (why not ?)

Linux stops when reached 2GB file out; but there was a little bit of memory available and the allocation rate was similar to previous trials

In Solaris, due to speed up the test I've ulimit -d 1024000, reached 2 GB file without stops itself (usually solaris continues, simply throws out additional data)

then some time later:

ch_malloc of 16392 bytes failed ch_malloc.c:57: failed assertion `0' Abort (core dumped)

with a while/loop ps, last line was:

PID RSS VSZ %MEM TIME STIME COMMAND 18246 1652488 1656144 41.1 31:23 09:22:35 slapcat

On my linux 2.6 system (64 bit), with a 2.5 million entry db, which is:

ldap00:/var/lib/ldap/slamd/64-2.5mil-db42# du -h *.bdb 84M cn.bdb 618M dn2id.bdb 85M employeeNumber.bdb 3.2G id2entry.bdb 3.7M objectClass.bdb 85M uid.bdb

this runs I've tried a db like:

ldap@labsLDAP:/TEST_producer/openldap-data> du -h *.bdb

3,0M testCode.bdb 2,9G dn2id.bdb 600M entryCSN.bdb 545M entryUUID.bdb 15G id2entry.bdb 1,9M objectClass.bdb 270M testId.bdb

So, that does mean one thing -- It definitely outgrew the 366MB of BDB cache defined. On the other hand, once it reached its max size, it stayed steady there until completion was reached.

In my trials, instead, allocation never stops :( Perhaps due to a greater DB ?

Paolo