[Date Prev][Date Next] [Chronological] [Thread] [Top]

FW: commit: ldap/libraries/libldap result.c

I am only assuming that this fixes the same hang seen in ITS#980. It's not
clear from the description that they're actually related. The hang that I
saw was no race condition, it was a consistent hang due to processing of
referrals that accompanied SearchResult messages.

In this situation, the referral was chased and fully processed, and then the
SearchResult message itself was discarded instead of returning it to the
caller. Of course, the ldapsearch command keeps calling ldap_result until it
sees the SearchResult message that it wants, so the next time it comes in it
hangs forever in a select() looking for a message that has already come and

I tested this using the scripts in ITS#1234, using both V3 and V2. The hang
only occurred when chasing V3 referrals, and that situation is now working
for me.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

-----Original Message-----
From: owner-openldap-commit@OpenLDAP.org
[mailto:owner-openldap-commit@OpenLDAP.org]On Behalf Of hyc@OpenLDAP.org
Sent: Tuesday, April 16, 2002 3:53 AM
To: OpenLDAP Commit
Subject: commit: ldap/libraries/libldap result.c

Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap

Modified Files:
	result.c  1.66 -> 1.67

Log Message:
ITS#818, ITS#980, ITS#1234 ldapsearch/referral hang - set refer_cnt to 0
after v3refs have been chased. They are fully processed by the time we get
back, so we should just return the current result message to the caller.


Changes are generally available on cvs.openldap.org (and CVSweb)
within 30 minutes of being committed.