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