sachidananda sahu wrote: > Hi All, > > Any one can give a thought on this ?
Your problem description makes no sense. Unless you're explicitly calling ldap_set_option in multiple threads, the option structure is read-only. The default libldap is not threadsafe, nor is it meant to be. You should probably be using libldap_r. > > > > On Thu, Aug 1, 2019 at 7:55 PM sachidananda sahu <[email protected] > <mailto:[email protected]>> wrote: > > > Hi All, > > I recently upgraded to openldap 2.4.47, it's working with single threaded > connection but with multi threaded getting problem due to global structure of > ldapoptions in init.c > > ------------------------- > init.c > ------------------------- > > *struct* ldapoptions > <http://opengrok-prd.eng.netapp.com/source/s?defs=ldapoptions&project=dev> > ldap_int_global_options > <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_int_global_options&project=dev> > = > { LDAP_UNINITIALIZED > <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_UNINITIALIZED&project=dev>, > LDAP_DEBUG_NONE > <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_DEBUG_NONE&project=dev> > LDAP_LDO_NULLARG > <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_NULLARG&project=dev> > LDAP_LDO_CONNECTIONLESS_NULLARG > <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_CONNECTIONLESS_NULLARG&project=dev> > LDAP_LDO_TLS_NULLARG > <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_TLS_NULLARG&project=dev> > LDAP_LDO_SASL_NULLARG > <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_SASL_NULLARG&project=dev> > LDAP_LDO_GSSAPI_NULLARG > <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_GSSAPI_NULLARG&project=dev> > LDAP_LDO_MUTEX_NULLARG > <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_MUTEX_NULLARG&project=dev> > }; > > > This global structure is accessed at multiple places (such as > ldap_pvt_tls_init_def_ctx > <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_pvt_tls_init_def_ctx&project=dev>, > alloc_handle > <http://opengrok-prd.eng.netapp.com/source/s?refs=alloc_handle&project=dev>, > ldap_int_tls_connect > <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_int_tls_connect&project=dev>, > *ldap_pvt_tls_destroy > <http://opengrok-prd.eng.netapp.com/source/xref/R9.6x/third_party/open_source/openldap/distro/libraries/libldap/tls.c#152>, > ldap_ld_free*) > > in tls2.c using the macro lo > <http://opengrok-prd.eng.netapp.com/source/s?defs=lo&project=dev>= > LDAP_INT_GLOBAL_OPT > > <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_INT_GLOBAL_OPT&project=dev>(); > > > So in case of multi threaded application multiple ldap connection will be > using this global structure, for example ldo_tls_ctx of lapoptions will be > used. > In one thread it can be creating a tls connection and in one it can be > destroying the connection. As it's global so it is getting corrupted. > > Is openldap library thread safe completely ? Because this variable seems > to be not for this tls context variable, is there any other way of using this > context . As i can see a local variable ldo_tls_ctx exist in dap > ld->ldc->ldap_options->ldo_tls_ctx structure, but it's just got assigned with > the same > address of global structure in ldap_int_tls_connect > <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_int_tls_connect&project=dev>. > > So can someone share some thoughts on it ? > > -- > Regards, > Sachidananda Sahu > > > > -- > Regards, > Sachidananda Sahu > +91-9035265767 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
