[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Fw: OpenLDAP Search bug?



Per Howard's request, here is the search information that produced that log:

startDN: "uid=5253257,ou=people,o=myorg,myorgroot=top,o=myorg.com"
filter: "(objectClass=wcomservice)"
scope: 1

There are only 10 entries under this uid, but it is searching through the
whole tree.

Andy

----- Original Message -----
From: "Howard Chu" <hyc@symas.com>
To: "Banzaitron" <banzaitron@adelphia.net>
Sent: Tuesday, September 10, 2002 2:24 PM
Subject: RE: Fw: OpenLDAP Search bug?


> Please repost the search query and filter that produced this log.
>
>   -- 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: owner-openldap-software@OpenLDAP.org
> > [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Banzaitron
> > Sent: Tuesday, September 10, 2002 12:35 PM
> > To: Kurt D. Zeilenga
> > Cc: openldap-software@OpenLDAP.org
> > Subject: Re: Fw: OpenLDAP Search bug?
> >
> >
> > 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
> > >
> >
> >
> >
>