https://bugs.openldap.org/show_bug.cgi?id=9135

Howard Chu hyc@openldap.org changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED

--- Comment #1 from Howard Chu hyc@openldap.org --- (In reply to Konstantin Andreev from comment #0)

Full_Name: Konstantin Andreev Version: 2.4.48, git/master/44a7b46/20191203 OS: Solaris 11.3 x64 URL: Submission from: (NULL) (79.135.238.172)

Here is a test case.

1) choose an attribute that has an equality index in your dit;

2) for this attribute choose a value that does not (and did not) exist in

the dit yet;

Let assume you chose [o=1] attr/val pair.

3) add MDB_IDL_DB_MAX+1 ( = 0x10000 = 65536 ) entries having [o=1]

attr/val pair.

4) delete last MDB_IDL_DB_MAX-1 of them in the order inverted as

compared to the order of addition

Now you have two entries having [o=1] attr/val pair. Let assume they are

| $ ldapsearch -s sub -b 'ou=T' '(o=1)' o
| dn: cn=1,ou=T
| o: 1
| 
| dn: cn=2,ou=T
| o: 1

5) delete one of the remaining entries, e.g. cn=2,ou=T

Repeat the search:

| $ ldapsearch -s sub -b 'ou=T' '(o=1)' o
| $

Nope, the remaining entry has been lost from the index forever. But it is still in the dit:

| $ ldapsearch -s one -b 'ou=T' '(objectclass=*)' o
| dn: cn=1,ou=T
| o: 1
|
| dn: ou=A,ou=T
| ...

You need to slapindex to restore `o' index to a valid state, but you may not know you need to repair the index.

The probability of this scenario is negligible, because indexed entries never form continuous block of ids of many-thousand length, but the code for this scenario exists and has a bug.

Thanks for the report. Fixed now in master.