Modify destroys entry (w/BerkeleyDB)

[Carl Litt <carl@execulink.com>]

I have started seeing problems with OpenLDAP 2.0.11 with BerkeleyDB
3.1.17.  I'll let the logs tell the story:

Aug 27 10:45:54 ldap1 slapd[21175]: conn=644228 op=7 MOD dn="mailLocalAddress=ljmyerscough@odyssey.on.ca,ou=passwd,o=Top"
Aug 27 10:45:55 ldap1 slapd[21175]: ldbm: ==> put: attempt to modify a read-only tree
Aug 27 10:45:55 ldap1 last message repeated 13 times
Aug 27 10:45:55 ldap1 slapd[21175]: idl_insert_key: idl_store returned -13
Aug 27 10:45:55 ldap1 slapd[21175]: ldbm: ==> put: attempt to modify a read-only tree
[The last 2 lines repeat about 10 times]
Aug 27 10:45:55 ldap1 slapd[21175]: conn=644228 op=7 RESULT tag=103 err=0 text=

After this, the entry can no longer be searched from o=Top.  It can
however be retrieved directly with a base scope.  It sounds like the
indexes are being corrupted?  When I regenerate the indices with
slapindex, the entry returns back to normal.

This is on a relatively stock Redhat 6.2 system with stock Berkeley DB
distribution (db3-3.1.17-4.6x.i386.rpm) and Rawhide's
openldap-2.0.11-1.src.rpm using the following ./configure options:

--with-ldbm-api=berkeley --with-slapd --without-slurpd --without-ldapd
--with-threads

I also had to make some changes to the spec, configure, and
build/openldap.m4 files in order to link with -ldb-3.1 instead of
-ldb3

This is all the debug info I have available.  The only times I have seen
this are after long process runtimes, but I don't know if that's related
other than by probabilities of failure.

I am guessing there are still issues with threading and/or BerkeleyDB,
so I recompiled --without-threads.  But it would be nice to get the
threading back for SMP.

Thanks,
Carl Litt
Network Administrator
Execulink Internet