Full_Name: Arran Cudbard-Bell
OS: OSX 10.10.1
Submission from: (NULL) (220.127.116.11)
Issue is fully documented here:
As libldap lacks a global initialisation function, the global config struct and
other global resources are initialised on the first call to either ldap_create,
ldap_get_option or ldap_set_option via a call to ldap_int_initialize.
Where multiple threads are spawned and each allocate a new handle using a
function that calls ldap_create, the lack of concurrent access protection in
ldap_int_initialize causes memory corruption.
There are a few ways this could be fixed. One is documented in the issue tracker
link above. There are likely better ones.
An alternative of fixing this would be to have public functions that can be used
to initialise any global resources before creating handles, and to free them
explicitly (instead of relying on atexit or a similar mechanism).
In terms of writing dynamically loadable/unloadable modules around libldap, the
second approach is preferred as any memory allocated on the heap could be
cleaned up prior to the module being unloaded.