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
- Let's see where ldo_tls_ctx get allocated.
ldap_pvt_tls_init_def_ctx( int is_server )
- 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 <hyc@symas.com mailto:hyc@symas.com> 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 <sachi059@gmail.com <mailto:sachi059@gmail.com> <mailto:sachi059@gmail.com <mailto:sachi059@gmail.com>>> 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 ? >