[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
- From: hyc@symas.com
- Date: Thu, 20 Jan 2011 21:53:44 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
hyc@symas.com wrote:
> 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.
>
Although googling for "Cyrus sasl reentrancy" does not leave me with
warm/fuzzy feelings.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/