Slapd halts almost sistematically on ldapsearch

["Walter Vendraminetto" <lists@zonatex.net>]

Hi folks,

I hope some one can help me ...

Scenario:
 I'm using OpenLdap (v 2.0.23 over GDBM - 1 Master + 2 Replicas) to
authenticate users on RH 7.3 (2.4.18). A replica runs also a Samba TNG
daemon and the Directory contains data for authenticate mail users via
qmail/courier-imap running on a 4th machine. 
To manage the accounts stored in OpenLDAP we use the ldaputils (http://www
pingworks.de/tech/ldaputils/) which made their job until few days ago. For
example we inserted the about 1500 users who log on the about 200 machines
in the laboratories.

Problem: 
when using the common procedure to add new users, since the beginning of the
year, the slapd daemon is stopped with LDAP_OPERATION_ERROR. After 'deep'
(not enough, yet!) investigation I discovered that the ldaputils issue a
search with a huge number of attributes. If the search fails (i.e. object
not present) no problem. If the search succeeds the slapd dies at 90% with
the message above (no core available). 
Once located that search op, I replicated it with the local ldapsearch
client: same result. 
The search directive is the following:

--------- STARTHERE ---------------
ldapsearch -x "(&(objectclassmailMessageStore qmailGI
D phonelist telephonenumber pwdCanChange script pwdLastSet category
uidNumber gidNumber postalcode 
lpprinted mailForwardingAddress birthdate fax home
phone pwdMustChange lmPassword homeDirectory cn mailReplyText acctFlags
shadowFlag loginShell 
mailAlternateAddress kickOffTime homeDrive uid smbHome 
mailQuota deliveryMode deliveryProgramPath country gecos description mail
qmailDotMode locality 
shadowWarning ntPassword lpdate lpquota logOffTime sh
adowLastChange profile pagerphone shadowMax qmailAccountPurge qmailUID
userPassword rid shadowMin 
streetaddress cellphone ntUid logOnTime sn givennam
e lpnote accountStatus groupRid
----------ENDHERE -----------

Above this I recently discovered (i'm working on it) that ACLs' complexity
are responsible of reduced performances.

Hints:
- Net::LDAP module was recently updated (Apr 02)


Solution:
Converting to Berkeley DB may solve ?
Any desync event may occour ?
What does the parameter 'sync' of the Net::LDAP lib do ?
Any Help?


Thank you very much in any case.