Re: Fw: OpenLDAP Search bug?

[Banzaitron <banzaitron@adelphia.net>]

OK, I redirected the output from my mystery search into a file (10 megs for
one search!) and found the following interesting output at the beginning of
the search (where it is trying to determine the candidate set of entries for
the search).  Note the "<= bdb_index_read: failed (-30990)" line:

search_candidates:
base="uid=5253257,ou=People,o=myorg,myorgroot=top,o=myorg.com" (0x00000698)
scope=1
=> bdb_filter_candidates
 AND
=> bdb_list_candidates 0xa0
=> bdb_filter_candidates
 DN ONE
=> bdb_dn2idl( "uid=5253257,ou=people,o=myorg,myorgroot=top,o=myorg.com" )
<= bdb_dn2idl: id=10 first=1689 last=1698
<= bdb_filter_candidates: id=10 first=1689 last=1698
=> bdb_filter_candidates
 OR
=> bdb_list_candidates 0xa1
=> bdb_filter_candidates
 EQUALITY
=> bdb_equality_candidates
=> key_read
<= bdb_index_read: failed (-30990)
<= bdb_equality_candidates NULL
<= bdb_equality_candidates id=0, first=0, last=0
<= bdb_filter_candidates: id=0 first=0 last=0
=> bdb_filter_candidates
 EQUALITY
=> bdb_equality_candidates
=> key_read
<= bdb_index_read 15284 candidates
<= bdb_equality_candidates id=15284, first=12, last=29997
<= bdb_filter_candidates: id=15284 first=12 last=29997
<= bdb_list_candidates: undefined rc=0
<= bdb_filter_candidates: id=15284 first=12 last=29997
<= bdb_list_candidates: undefined rc=0
<= bdb_filter_candidates: id=15284 first=12 last=29997
bdb_search_candidates: id=15284 first=12 last=29997
...
<skipped 30000 entry searches>

Apparently it is unable to read an index (what index I'm not sure?) and then
decides that the entire tree is fair game for the search.  The following are
my indices:

index           ou,o            eq
index           cn              pres,eq
index           myorgfirstname,myorglastname,myorgvportalaccessinfo
pres,eq,su
b
index           myorggroupname,myorgworkphonenumber      pres,eq,sub
index           uid,myorgdn,myorgroot,myorgsn              pres,eq
index           objectclass,myorgadmin,myorgan    pres,eq
index           myorgsecondaryuid                pres,eq

I'm using BDB 4.0.14, and the latest OpenLDAP build from engineering 2.1.X.

Any clues where to go from here?  I have already rebuilt my indices and
deleted all data and reimported it, with no change in behavior.  I'm stuck
with no clue how to proceed on this.

Thanks,
Andy

----- Original Message -----
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
To: "Banzaitron" <banzaitron@adelphia.net>
Cc: <openldap-software@OpenLDAP.org>
Sent: Monday, September 09, 2002 4:26 PM
Subject: Re: Fw: OpenLDAP Search bug?


> At 02:35 PM 2002-09-09, Banzaitron wrote:
> >I have set logging to show everything and the problem is that the
candidate
> >set as you call it is the ENTIRE TREE!!!  It is ignoring my start DN and
it
> >is searching below AND above the DN I pass, regardless of the search
scope.
>
> In one of your previous post, you described one case where
> you ONLY changed the filter from a (objectClass=*) to
> (objectClass=myorgservice) caused the candidate to be
> quite large (presumable all entries in the database).
>
> This is odd because, assuming everything else is equal
> (including DN and scope), the latter search candidate
> set should be subset of the former search candidate
> set.
>
> Looking at the logs, one can determine which indexing
> component(s) caused this oddity.
>
> You can do the same with DNs and scope subtree.  That is,
> a search of a DN with scope subtree should have a
> candidate set which is a subset of the search for its
> parent with scope subtree.   If not, that would be odd.
>
> Looking at the logs, one can determine which indexing
> component(s) caused this oddity.
>
> But a candidate set which happens to include an entry
> which doesn't match all of the search criteria (including
> DN, scope, filter, etc.) isn't odd.  It's called a
> candidate set because it includes, in addition to
> all entries which do match the criteria, some number
> of entries that do not.  The number of these entries
> depends on how effective the indexing system was on
> reducing the candidate set from all entries to the
> subset of entries matching all of the search criteria.
>
> Kurt
>