https://bugs.openldap.org/show_bug.cgi?id=9190
--- Comment #1 from Quanah Gibson-Mount quanah@openldap.org --- I've tried reproducing via a script, and while I get the same searches, I do not get the err=4. The difference seems to be the fact that when the error is seen, the system is under load with multiple connections and searches occurring, while my test is while the system is idle. It makes me wonder if this is an initialization bug similar to bug#9052.
Mar 21 22:44:32 localhost slapd[30041]: conn=2623 fd=23 ACCEPT from IP=xx.yyy.zz.aa:38002 (IP=0.0.0.0:389) Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=0 BIND dn="cn=admin,dc=xxx,dc=yyy" method=128 Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=0 BIND dn="cn=admin,dc=xxx,dc=yyy" mech=SIMPLE ssf=0 Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=0 RESULT tag=97 err=0 qtime=0.000017 etime=0.671021 text= Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=1 SRCH attr=namingContexts Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000034 etime=0.675941 nentries=1 text= Mar 21 22:44:32 localhost slapd[30041]: conn=2623 op=2 SRCH base="dc=xxx,dc=yyy" scope=2 deref=0 filter="(uid=*)"
(search continues until I kill it, as we clearly never hit the size limit)