[email protected] wrote: > On Fri, Apr 28, 2017 at 02:52:44PM +0000, [email protected] 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 protected] 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 libldap_r. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
