Re: (ITS#4856) Back-SQL + Subtree search hits 'assert(0)'

[ando@sys-net.it]

vargok@yahoo.com wrote:
> Full_Name: K Vargo
> Version: 2.3.32
> OS: Linux (RH-EL4)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (128.237.233.195)
> 
> 
> Given a Base-DN, Subtree scoped ldapsearch, while the database contains
> non-DN-matching items runs up against the 'assert(0)' in Back-SQL/search.c
> +2186.
> 
> Based on how the selection works, there doesn't appear to be a reason for the
> assertion.  The FIXME does not indicate WHY the dnIsSuffix should never fail:
> the comparison in dnIsSuffix tries to compare incompatible-dn records and fails
> -- as it should.
> 
> Removing the assertion provides for the expected behavior in my simple case.
> Basically, it appears that a Base-DN is not being pre-filtered by the Back-SQL
> selection search, so it needs to be filtered by the dnIsSuffix check.
> 
> While I could certainly see that my metadata is not correct (stock metadata from
> 2.3 + changes from 200511/msg00504.html) I'm not sure an assert(0) is
> appropriate.
> 
> Additionally, there's no indication that back-sql can't support data with
> multiple DNs.

Actually, your assumption is partially incorrect, since back-sql doesn't 
do prefiltering of the DN if the search is rooted at the database's 
suffix (it's called the "subtree shortcut") unless you tell it 
otherwise, by using "use_subtree_shortcut no" (the docs state it's the 
default; this is wrong).

I admit assert(0) there is a bit too strong, but I believe it was put 
there to catch this type of problems.  I think the "right" solution, 
apart from fixing the docs, consists in removing the assertion.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------