Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection

[hyc@symas.com]

timo.aaltonen@aalto.fi wrote:
>   	Hi
>
>     Here's some information that Stephen asked would be of use. There is
> one forest, one domain, but three sites in the layout. The functional
> level of the forest and the domain is W2008, but the servers have 2008R2.
>
> And the full backtrace of the hung process:

> #3  0x00007f8f652f3bcb in ldap_pvt_thread_mutex_lock
> (mutex=0x7f8f6553fc80)
>       at /tmp/buildd/openldap-2.4.23/libraries/libldap_r/thr_posix.c:296
> No locals.
> #4  0x00007f8f653010bf in ldap_sasl_interactive_bind_s (ld=0x2117c20,
> dn=0x0,
>       mechs=0x210d530 "GSSAPI", serverControls=0x0, clientControls=0x0,
> flags=2,
>       interact=0x7f8f61405120<sdap_sasl_interact>, defaults=0x2124a50) at
> sasl.c:426
>           rc = -1921681294
>           smechs = 0x0

This particular mutex seems kind of bogus to me; the code is from rev 1.31 in 
June 2001. Perhaps back then it was unsafe to have multiple SASL operations 
outstanding at once; I would expect that was only an issue in the Cyrus 1.5 
days and it should be safe now with Cyrus 2.x. We should probably just delete 
this mutex.

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