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

ITS#3985 test039 hangs on Windows

There appears to be more than one failure condition here. Aside from the extremely slow execution when the test succeeds, I still see infinite hangs occurring.

My latest run from last night is still running now, and slapd.3.log shows there is a msgID in Request Completed state that has been on the queue for the past 12 hours with no other activity occurring on any of the clients or servers. It appears that someone has lost track of this request after chasing a referral unsuccessfully.

I'm finding the lm->lm_chain/lm_chain_tail processing code to be rather unconvincing here, wondering if it is related to the loss of state.

In particular, the use of lm_chain_tail in ldap_parse_result makes little sense. The initial code assumes that the message pointed to by lm_chain_tail is the first result of interest. Then after that parse is done, the bit about "Find the next result..." acts as if there may be another result after the tail. Clearly if we were already on the "tail" message there should not be anything following it. I believe the use of chain_tail here to optimize the retrieval of the result message is a bad idea.

On the other hand, when exactly is it possible for a single request to have more than one result message? Googling for LDAP_MORE_RESULTS_TO_RETURN shows that at least Sun/Netscape think this can only happen as the result of a SASL Bind request. But there's nothing in the protocol spec (or LDAPbis drafts) that mentions this. It appears that this error code has no real application, and "Find the next result..." is wasted effort. What's really going on here?

 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/