Hi Anton, The ldap sdk 4.1 crash environment is happening with SSL. We haven't been able to verify it on non-Windows platforms as of yet. Is there a known problem with ldap sdk 4.1 ldap_unbind with SSL enabled on Windows.
On a separate note, we are also observing segamentation faults with ldap sdk 5.12 on Solaris with ldap_unbind(). Has such a crash been encountered before? ----------------- lwp# 8 / thread# 8 -------------------- ff1d2c24 nsldapi_clear_from_cb_pollfds (69bfe40, 0, 1880e08, ff1343b8, 16af468, 0) + 2c ff1d62ac nsldapi_free_connection (69bfe40, 20e0188, 0, 0, 1, 1) + 28 ff1e0a48 ldap_ld_free (69bfe40, 0, 0, 1, 0, ff132870) + 210 ff1e07e8 ldap_unbind (69bfe40, 0, 2050010, 5420000, 1, 1630468) + 10 Thanks & Regards, Pradnyesh Anton Bobrov wrote: > even if say you know you hitting some know issue with 4.x it doesnt > do you any good because you cant get any fixes for 4.x today, back > ported or otherwise. with that said you might wanna check if : > > - the problem happens on Doze only. > - you are doing SSL on that handle. > - you can confirm that problem is > *not* reproducible with 5.x or 6. > > Pradnyesh wrote: > > Hi All, > > > > We have a multi-threaded server that uses netscape ldap c sdk 4.1 in > > it's older release. We are experiencing some random crashes, while > > freeing memory, in the call to ldap_unbind() in our code. Due to its > > random nature, We haven't been able to create a test case for the > > issue so far. > > > > Our environment is as follows > > > > - The backend directory server is AD.NET 2003 and our server is > > running on a Win 2003 box. AD.NET is by default configured to close > > idle ldap connections every 15 mins. > > - ldap sdk version is 4.1. [We have alread migrated to ldap sdk 5.X in > > the later versions of our product.] > > - Another thing that is hampering us is that there are no Windows > > symbol files[pdb] available for ldap sdk 4.1, which prevents us from > > capturing an exact stacktrace inside ldap_unbind. > > - Our server creates a pool of ldap connections with separate > > dedicated threads to create new connections as well as clean-up old > > connections. > > - multiple worker threads can share the same ldap connection handle at > > the same time. e.g. you can have multiple ldap_simple_bind going > > asynchronously over the same ldap connection handle at the same time. > > - we have registered callback functions for createmutex, lockmutex, > > unlockmutex, freemutex, getthreadid, getldaperror etc. > > - we have confirmed via logging that we are not calling ldap_unbind > > twice on the same ldap handle. > > > > Please let me know if anyone has any suggestions. > > > > I also noticed that there were already a couple of posts regarding > > crashes in ldap_unbind. Did we have any resolutions for these? > > > > Heroux, Bernard R wrote on 3/30/2006 > >> Every so often the ldap_unbind_s will cause a crash. This occurs even > >> when checking the ldapHandle for NULL before calling the unbind. > > > > Mike wrote on 3/2/2006 > >> I was reading through the documentation on how to handle failover or > >> being disconnected from an LDAP server in my apps. One method is to > >> call ldap_unbind and reconnect and rebind, while the other method is set > >> the LDAP_OPT_RECONNECT option and only rebind (i.e. don't call > >> ldap_unbind). > >> > >> http://www.mozilla.org/directory/csdk-docs/using.htm#handle_failover > >> > >> We had been using the former of the two methods, but some of our apps > >> were coring randomly during the ldap_unbind call > > > > Thanks & Regards, > > Pradnyesh > > _______________________________________________ > > dev-tech-ldap mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-tech-ldap _______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
