[email protected] wrote: > Full_Name: Doug Leavitt > Version: 2.4.44 > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (137.254.4.13) > > > There is a race condition in ldap_int_utils_init that can be triggered when > multiple threads enter ldap_int_utils_init from ldap_init_initialize about the > same time. The done flag gets set immediately, before the various mutexes are > initialized. If thread A sets done, and thread B tests for done==1 before > thread > A has completed the mutex inits, thread B can attempt to use an uninitialized > mutex and fail/core dump etc. > > Additionally if judt the done=1 is moved to the bottom of the function thwo > threads can both be initializing the same mutexes multiple times causes other > mayhem. > > The short term workaround for Solaris (THR APIs) is to move setting of done=1 > to > after the mutex inits, and to protect the mutex inits using another statically > initialized mutex within ldap_int_utils_init.
> I know a similar workaround could be made for POSIX threads and possibly some > of > the other supported thread models, but this approach seems kludgely. Static initializers would be the simplest fix, certainly. On Windows we'd have to use something similar to pthread_once() for initialization, instead. > I suspect the correct solution may be to somehow refactor ldap_int_utils_init > out of libldap and into libldap_r in a cleaner multi-platform manner than the > example above. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
