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]>> 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]>>>
> 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/
