RE: Index corruption and crash in back-ldbm (ITS#2348)

[hyc@highlandsun.com]

I've committed a fix to CVS HEAD as described in my previous message. Please
test.

I hardcoded dbc_maxid at 4 and dbc_maxindirect at 8 so I could test with a
small data set.

The proof of the fix for me is running slapindex under gdb, with a breakpoint
on idl_store. When run after a fresh slapadd, slapindex should be a no-op and
thus should never invoke idl_store. If it does, then a bug remains. It runs
cleanly for me.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: vek@pharmapartners.nl [mailto:vek@pharmapartners.nl]

> On Wed, 5 Mar 2003 hyc@highlandsun.com wrote:
>
> > Date: Wed, 5 Mar 2003 23:08:18 GMT
> > From: hyc@highlandsun.com
> > To: openldap-its@OpenLDAP.org
> > Subject: RE: Index corruption and crash in back-ldbm (ITS#2348)
> >
> > Ignore that previous message. Your bug analysis and patch
> are exactly right.
> > I am committing it to both 2.1 and 2.0.
> >
>
> It wasn't complete, though.  The events shown below can be reproduced
> by running slapindex without erasing the indexes first, thus when
> all the id entries already exist.  If you lower
> db->dbc_maxids while testing
> it would happen much sooner.
>
>
> Must select the block where id is greater OR EQUEAL to the lower
> bound for this block.  If id is equal to the lower bound and
> the previous block is selected for insert then the following message
> may be triggered.
>
>    "idl_insert_key: id %ld is already in next block\n"