Thanks

My application is multithread. I've had a call to ldap_get_option(NULL, LDAP_OPT_API_INFO, &ldapi) before spawning threads, but here the crash occurred also in ldap_initailize but in ldap_ld_free(). I addition, I won't call ldap outside my thread.

The full stack trace is : #0 0xb7e93473 in strlen () from /lib/tls/i686/cmov/libc.so.6 #1 0xb3a191f9 in ber_strdup_x (s=0x6a626f28 <Address 0x6a626f28 out of bounds>, ctx=0x0) at memory.c:640 #2 0xadd2fd66 in ldap_charray_dup (a=0xb313a324) at charray.c:164 #3 0xadd26883 in ldap_url_dup (ludp=0x8b83798) at url.c:1191 #4 0xadd26912 in ldap_url_duplist (ludlist=0x8b83798) at url.c:1217 #5 0xadd11b34 in ldap_create (ldp=0xb32e0dc8) at open.c:149 #6 0xadd11de1 in ldap_initialize (ldp=0xb32e0ec0, url=0x8946d20 "ldap://ldap:389") at open.c:225

I have same thing with the 2.3.38

Damien Doiselet

Pierangelo Masarati a écrit :

Only issues occurring with either the latest release (now 2.3.28) or HEAD code ought to be considered, as they might be related to already known and perhaps solved problems. Please check with a fresh build from 2.3.28.

In the meanwhile, it might be worth checking:

• is your application multithread?

• in case it is, is the first call to a libldap routine occurring __before__

starting multiple threads, or after? If after, then fix your project by adding a call to an LDAP routine (e.g. ldap_set_option() with an option that does not require a LDAP* handle) __before__ spawning threads.

• can you test your development using a libldap library containing debug

symbols, in order to provide helpful information?

p.