Hello folks, We have been running openldap-2.3.32 on SLES64 for a while with no problem. However, recently a couple of packages were upgraded (not including openldap), and we noticed that some applications started to consume 100% of CPU in a loop that never ended. After doing some investigation we found that it was due to a bug in a list traversal of OpenLDAP that had been fixed in mainline already. This is the patch in question, which was introduced in the commit referenced at the end of the email [1]: --- openldap-2.3.32/libraries/libldap/request.c.orig 2010-05-27 02:22:38.000000000 +0200 +++ openldap-2.3.32/libraries/libldap/request.c 2010-05-27 02:22:50.000000000 +0200 @@ -916,7 +916,7 @@ ldap_chase_v3referrals( LDAP *ld, LDAPRe if ( lp == origreq ) { lp = lp->lr_child; } else { - lp = lr->lr_refnext; + lp = lp->lr_refnext; } } if ( looped ) { So, these apps probably started to interact differently with OpenLDAP. The thing is that now these applications are taking much more time to complete execution than before. As a simple test, I tried to replace the above fix with a call to "break", which would mimic the old behavior back when applications didn't execute that code path: } else { - lp = lr->lr_refnext; + break; } To my surprise, the execution time of those apps went back to normal. Since I don't have experience with OpenLDAP nor I have a good understanding on many of its concepts, I'd like to ask you what's the impact on not chasing all referrals from the linked list? I read in the comments of try_read1msg() that if chasing fails then the referral is passed back to the application. Can I assume that try_read1msg() is basically caching that information just in case the caller needs it? What is that chasing used for? Thank you very much! Lucas [1] http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/request.c.diff...