[Date Prev][Date Next]
RE: Index corruption and crash in back-ldbm (ITS#2348)
I've committed a fix to CVS HEAD as described in my previous message. Please
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
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com]
> On Wed, 5 Mar 2003 firstname.lastname@example.org wrote:
> > Date: Wed, 5 Mar 2003 23:08:18 GMT
> > From: email@example.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"