First of all, I am paraphrasing. No one is hiding anything from you = Pierre. You need only ask.=20

...

It is supposed to be a bug. It's also the reason I asked from the beginning to see the real configuration, real data and real operation causing the issue. If you keep hiding essential details, and only =

provide

...

bits of information each time, it'll take ages to just discover where =

the

...

issue is.

...

So now the only way to keep this ITS open is to see your ENTIRE =

slapd.conf

...

(except passwords, of course). An even better alternative would be to receive a sanitized slapd.conf, a LDIF and a search operation based on ldapsearch that clearly illustrates the issue, like what I posted a =

couple

...

of postings ago.

Here, the entire sanitized config. I left out the ACL file (the include = statement at the very end), but the behavior in question was happening = to the rootdn user as well, meaning ACLs weren't the culprit. I also = removed 14 of 15 of the syncrepl stanzas for brevity, as they were all = the same aside from hostname/IP.

NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote the = original (dysfunctional) position vs the current (functional) position.

I can't see any difference in behavior with the configuration in ftp://ftp.openldap.org/incoming/slapd-its6471-1.conf, the data and the ldapsearch command described in my previous posting (the only difference is that now, after "./run -b hdb test003" you need to manually create directory "testrun/db.2.a" for the log database, and bind as the rootdn to perform the search). I tried both HEAD and current re24 code, which should not differ much from 2.4.21. The only modifications to configuration are related to: statically built backends/overlays, no ACLs, no TLS. Also, valgrind does not show anything strange (like dangling pointers or so) which could be symptoms of doing nasty things with memory that make my setup work "by chance".

p.