[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
> > >
> >
> >
> >
>