https://bugs.openldap.org/show_bug.cgi?id=9272

Issue ID: 9272 Summary: Invalid search results for subordinate/glued database Product: OpenLDAP Version: 2.4.47 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: grapvar@gmail.com Target Milestone: ---

Here is a trivial test case. Look at the following bunch of glued dit's/databases, declared in this order:

| suffix ou=a,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=2,ou=T # subordinate; contains only one (top-level) entry | suffix ou=b,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=T # master database, has two entries, top-level | ` ou=1 # ... and this child entry

let's query the united database:

| $ ldapsearch -b ou=1,ou=T -s sub '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | dn: ou=b,ou=1,ou=T

Nice! But wait, what if ...

| $ ldapsearch -b ou=1,ou=T -s sub -E!pr=2/noprompt '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | | # pagedresults: cookie=//////////8=

... BANG! ... | Server is unwilling to perform (53)

The problem is the glue_op_search(), which has issues

* different parts of code make different assumptions about data structures * different parts of code track state inconsistently * code that looks like a highly probably dead code

I mean that likely possible to build another bug-triggering test cases, and glue_op_search() needs not just a fix of the bug above, but intense cleaning and structuring.