sachidananda sahu wrote: > many thanks for the information. > Now have couple of queries. > > Then which call i should use to create the local context and destroy the tls > context.
None. The context is created automatically and used as needed. The context is per-process state, not per-thread state. No threads should be trying to destroy the context. The reference implementations are in clients/tools in the source tree. > > Currently i was calling > ldap_start_tls_s->ldap_int_tls_start->ldap_int_tls_connect : here it was > doing ctx > <http://opengrok-prd.eng.netapp.com/source/s?defs=ctx&project=dev>= ld > <http://opengrok-prd.eng.netapp.com/source/s?defs=ld&project=dev>->ld_options > <http://opengrok-prd.eng.netapp.com/source/s?defs=ld_options&project=dev>.ldo_tls_ctx > <http://opengrok-prd.eng.netapp.com/source/s?defs=ldo_tls_ctx&project=dev>;, > So as this connection is newly started and to add tls context over LDAP we > call > ldap_start_tls_s .....So when we should allocate the assign memory for this > local context. > > Currently It;s going for alloc_handle and creating a default context using > global and assigning it to local context. > > Similarly many places it access the global option->ldo_tls_ctx many places, > which function we should use for the destory of the context, considering > multiple > threads are there and creating and destroying connection. > > If any reference implementation link also there, you can share. > > Many thanks Howard for your insights. > > > > > On Tue, Aug 6, 2019 at 10:42 PM Howard Chu <[email protected] > <mailto:[email protected]>> wrote: > > sachidananda sahu wrote: > > Hi Howard, > > Thanks for your response. I may be missing something, but let me share > my thoughts based on code. > > > > ldap_set_option called from many threads, not only that even > ldap_int_tls_connect, ldap_pvt_tls_init_def_ctx as multiple thread can > connect to LDAP server. > > Based on code lookup, i feel not every members of option structure is > read only. > > > > Let's consider ldapoptions->ldo_tls_ctx which is global and can be used > by many threads. Suppose there is two threads and thread A may be at point 1 > and > thread > > B may be at point 2, based on scheduling chances of getting it messed > is more, which problem i am facing now. Have a look and please share in case > my > > assumptions are wrong or i am missing something. > > init_def_ctx only gets called from alloc_handle() if there was no > existing ctx. > > > > tls2.c > > --------------------------- > > > > 1. Let's see where ldo_tls_ctx get allocated. > > ldap_pvt_tls_init_def_ctx( int is_server ) > > > 2. Let's see where it's getting freed. ldo_tls_ctx the same from global > option context. > > > > *ldap_pvt_tls_destroy( void )* > > { > This is an OpenLDAP-specific private API. If you're calling this > function, you're misusing the API. > > > On Tue, Aug 6, 2019 at 9:44 PM Howard Chu <[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> > wrote: > > > > 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]> <mailto:[email protected] > <mailto:[email protected]>> <mailto:[email protected] > <mailto:[email protected]> <mailto:[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 ldap_int_global_options = > > > { LDAP_UNINITIALIZED , LDAP_DEBUG_NONE, > > > LDAP_LDO_NULLARG , > > > LDAP_LDO_CONNECTIONLESS_NULLARG, > > > LDAP_LDO_TLS_NULLARG, > > > LDAP_LDO_SASL_NULLARG , > > > LDAP_LDO_GSSAPI_NULLARG, > > > LDAP_LDO_MUTEX_NULLARG };, > > > > > > > > > This global structure is accessed at multiple places (such as > ldap_pvt_tls_init_def_ctx , alloc_handle, ldap_int_tls_connect , > *ldap_pvt_tls_destroy , > > ldap_ld_free*) > > > > > > in tls2.c using the macro lo = LDAP_INT_GLOBAL_OPT > > > (); > > > > > > 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. > > > > > > So can someone share some thoughts on it ? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
