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.

Currently i was calling ldap_start_tls_s->ldap_int_tls_start->ldap_int_tls_connect : here it was doing ctx = ld->ld_options.ldo_tls_ctx;, 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 <hyc@symas.com> 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 <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 ?
> >

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/