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
Pierangelo Masarati a écrit :
Only issues occurring with either the latest release (now 2.3.28) or
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?