[Date Prev][Date Next]
Re: (ITS#8648) sasl_client_init called concurrently causes issues
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8648) sasl_client_init called concurrently causes issues
- From: email@example.com
- Date: Tue, 02 May 2017 19:33:08 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> On Fri, Apr 28, 2017 at 02:52:44PM +0000, firstname.lastname@example.org wrote:
>> I tried cyrus-sasl-2.1.25 and the issue doesn't seem to happen. I'll see
>> if I can isolate the related change.
> SASL version was a red herring. I accidentally linked with Debian's
> libldap (2.4.31) when I tested that. Mea culpa.
> The culprit does indeed seem to be the ITS#6798 change, as Quanah
> suggested. Reverting b483ee1a ("Drop ldap_int_sasl_mutex") on RE24 and
> linking with libldap_r makes my test program work.
> Since the proof-of-concept patch I posted above also makes my test
> program work, I'm back to thinking that calling sasl_client_init
> concurrently is the real bug here.
>> On Fri, Apr 28, 2017 at 04:43:33AM +0000, email@example.com wrote:
>>> If I'm right about this bug, I suppose the right fix is to wrap sasl_client_init
>>> in a new mutex.
>> ... of course that idea's half-baked, because libldap doesn't *have*
>> mutexes. hmm.
> I'm still not happy with the idea of calling sasl_client_init from
> ldap_int_initialize, as it does a bunch of work (loading plugins and
> such) that non-SASL users don't care about. However, I haven't as yet
> thought of another fix that works for libldap as well as libldap_r.
> Would love to hear others' thoughts on this. Maybe fixing for libldap_r
> only (and documenting that) is a good enough compromise?
Yes, if the problem only exists in concurrent use then it's only relevant to
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/