Description of problem: Customer is reindexing several times same attribute using the console (on-line reindex). Second time using a matching rule. The index shows corrupt by using dbverify. How reproducible: rather always. Steps to Reproduce: 1. create instance / suffix 2. import 60 entries of this shape: dn: uid=user2,ou=people,o=redhat objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgperson objectclass: posixAccount uid: user2 userpassword: user2 uidnumber: 2 gidnumber: 2 cn: user2 sn: user2 3. Add index by uidnumber: dn: cn=uidnumber,cn=index,cn=userroot,cn=ldbm database,cn=plugins,cn=config changetype: add objectClass: top objectClass: nsIndex cn: uidnumber nsSystemIndex: false nsIndexType: pres nsIndexType: eq 4. Apply index /usr/lib64/dirsrv/slapd-server2/db2index.pl -n userroot -D "cn=directory manager" -w secret12 -t uidnumber 5. wait for the reindex to be finished. 6. modify index in this way: dn: cn=uidnumber,cn=index,cn=userroot,cn=ldbm database,cn=plugins,cn=config changetype: modify add: nsMatchingRule nsMatchingRule: integerOrderingMatch 7. Re-apply index /usr/lib64/dirsrv/slapd-server2/db2index.pl -n userroot -D "cn=directory manager" -w secret12 -t uidnumber 8. Stop server 9. Run dbverify [root@rh6 ~]# /usr/lib64/dirsrv/slapd-server2/dbverify [29/Jun/2015:18:25:33 +0200] - libdb: Page 1: out-of-order key at entry 124 [29/Jun/2015:18:25:33 +0200] - libdb: Page 1: out-of-order key at entry 146 [29/Jun/2015:18:25:33 +0200] - libdb: Page 1: out-of-order key at entry 168 [29/Jun/2015:18:25:33 +0200] - libdb: Page 1: out-of-order key at entry 190 [29/Jun/2015:18:25:33 +0200] - libdb: /var/lib/dirsrv/slapd-server2/db/userRoot/uidnumber.db4: DB_VERIFY_BAD: Database verification failed [29/Jun/2015:18:25:33 +0200] DB verify - verify failed(-30972): /var/lib/dirsrv/slapd-server2/db/userRoot/uidnumber.db4 Actual results: index corrupted. Expected results: not corrupted. Additional info: Easy workaround: reindex off-line.
{{{ a->ai_substr_lens = b->ai_substr_lens; }}} ai_substr_lens is an array, so you'll have to dup the array and copy the elements.
Replying to [comment:4 rmeggins]:
Oops. Thanks, Rich!! I'm fixing it... --noriko
git patch file (master) -- fixed the issue pointed out by Rich in comment:4 (Thank you, Rich!) 0001-Ticket-48212-Dynamic-nsMatchingRule-changes-had-no-e.patch
git patch file (master) -- CI test 0002-Ticket-48212-CI-test-added-test-cases-for-ticket-482.patch
Reviewed by Rich (Thank you!!)
Pushed to master: df13210..a533145 master -> master commit d967972 commit a533145
Pushed to 389-ds-base-1.3.4: a980b79..0e079ab 389-ds-base-1.3.4 -> 389-ds-base-1.3.4 commit d15beff commit 0e079ab
Pushed to 389-ds-base-1.3.3: d9b77f5..a71b48c 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit 96cb151 commit a71b48c
Pushed to 389-ds-base-1.2.11: 993e37a..84b03a8 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit 84b03a8
Metadata Update from @rmeggins: - Issue assigned to nhosoi - Issue set to the milestone: 1.2.11.33
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1543
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.