Re: Modify destroys entry (w/BerkeleyDB)

[Markus Storm <Markus.Storm@mediaWays.net>]

Maybe a bit too early to tell, but it looks like the patch to filterindex.c
(contained in HEAD and REL_ENG_2, but not in RELEASE) fixed this for us.
No more warnings since.

Not sure whether this also fixes the index corruption, though.
Can you upgrade to REL_ENG_2, re-index the database and see if you still
see corruption ?


Btw, syslog still tells me 

"slapd[22879]: ldbm: ==> set_alloc: method meaningless after open"

Can I safely ignore this or is it indicative of another bug ?

regards,
Markus


Carl Litt wrote:
> 
> 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