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