Howard Chu wrote:
Howard Chu wrote:
Hallvard B Furuseth wrote:
http://folk.uio.no/hbf/test008out2.tbz ldapsearch.flt = ldif.flt + cn=James A Jones 4,ou=People,dc=example,dc=com .
I just got a similar failure in RE24. Looks like the same thing Aaron reported. Too bad it takes so long to reproduce it.
I'm using this assert to try to catch it in the act:
RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/delete.c,v retrieving revision 1.162 diff -u -r1.162 delete.c --- delete.c 28 Aug 2007 22:13:56 -0000 1.162 +++ delete.c 3 Dec 2007 15:27:19 -0000 @@ -199,6 +199,8 @@ "<=- " LDAP_XSTRING(bdb_delete) ": no such object %s\n", op->o_req_dn.bv_val, 0, 0);
assert(0);if ( matched != NULL ) { rs->sr_matched = ch_strdup( matched->e_dn ); rs->sr_ref = is_entry_referral( matched )It took about 10 iterations of test008 to trip it again. Still looking at the core file, the EntryInfo for the target entry but it looks like it couldn't be found in the id2entry DB. Odd.
Very strange. The entry could not be found because cache_find_ndn returned an EntryInfo for the previous incarnation of the entry, which contained the old entryID. This is extremely odd given that bdb_cache_delete_internal has already successfully deleted the old record from the cache, before the previous Delete completed. On the subsequent Add, bdb_cache_add fails to insert the new EntryInfo because it has the same RDN as the old.
On my tests it almost always fails with the new entryID == 84 and the previous == 83. That's also pretty suspicious, no idea what it means.
Still sprinkling asserts in the code to try to find what's going on.