I'm am tracking down an issue now that comes down to this: after calling
ldapssl_client_init for the first time, when ldap_simple_bind_s is called,
the calling thread is taken over and the function returns on a different
thread.
I know this sounds bizarre, but I have proven it to myself by modifying the
ssnoauth SDK sample to call ldap_simple_bind_s before calling ldap_search_s
and calling the Win32 API GetCurrentThreadId before and after the call to
bind:
<<ssnoauth.c clip>>
dwTID = GetCurrentThreadId();
/* authenticate to the directory as the Directory Manager */
if ( (ret = ldap_simple_bind_s( ld, MGR_DN, MGR_PW )) != LDAP_SUCCESS )
{
ldap_perror( ld, "ldap_simple_bind_s" );
return( 1 );
}
dwTID = GetCurrentThreadId();
<<clip>>
I've tested this with both the 4.14 and the 5.0 SDK. In the case of the 5.0
SDK, the address on top of the original thread's call stack after it gets
taken over (i.e. the program is paused immediately after the second call to
GetCurrentThreadId) is LIBNSPR4! 300282c0.
FWIW I running VC6 SP5 on Win2k Pro SP2 and I'm connecting to a Novell
NDS8.something LDAP server.
If someone has any kind of thoughts, please let me know.
I tried the mozilla copy of the LDAP directory code, but the SSL funtions
are missing (export restrictions I assume)
Chris Conti
[EMAIL PROTECTED]
