Comment 6 for bug 507089

Created an attachment (id=210379)
New stack trace that points to: libldap50 conflict.

Here's the related bug for PADL nss_ldap:
http://bugzilla.padl.com/show_bug.cgi?id=203
I did more investigation on the problem at their request and
found that there seems to be a conflict between the libldap50.so
included with the binary version of Mozilla, and whatever the
default libldapxxx.so that is installed on the user's distribution.
This occurs with nss_ldap because it causes libc to drag in the
default ldap library via NSS for anything that does user name
translation. This seems to react poorl with the Mozilla libldap50
library. Included is the text snippit from my most recent comment
on the PADL bug, and the stack trace from that bug.

From PADL Bug:
Problem is not in nss_ldap. It's a Thunderbird bug

I brought up thunderbird under gdb on my desktop with LDAP user env and not
nscd. Thunderbird died a messy death in strtok() with corrupted stack, so no
trace. No problem. Turns out this is luckily the first call to strtok(), so
was able to 'break strtok' and get a trace.

It turns out that thunderbird has its own version of libldap.so called
libldap50.so with a version of ldap_str2chararray that conflicts with that in
/usr/lib/libldap-2.2.so.7. The version in Thunderbird's libldap50 is called
unexpectedly and it looks like this is causing libldap-2.2 to poop its pants.

As an experiment, I moved /usr/thunderbird/libldap50.so aside and symlinked it
to the linux /usr/lib/libldap-2.2.so.7, and sure enough Thunderbird worked
perfectly.

Therefore, this is a problem with the binary release of Thunderbird not
handling conflicts in system LDAP libraries. Nothing wrong with nss_ldap from
the looks of it.