Description of problem: Upgrading to thunderbird-16.0.1-2 and xulrunner-16.0.1-2 causes an LDAP query to hang the CPU core and return no results. This happens in both the compose screen and Address Book. Downgrading both thunderbird and xulrunner to 16.0.1-1 "fixes" the problem, LDAP works as expected. Version-Release number of selected component (if applicable): thunderbird-16.0.1-2.fc17.x86_64.rpm xulrunner-16.0.1-2.fc17.x86_64.rpm thunderbird-lightning-1.8-1.fc17.x86_64 Extra addons via XPI downloads: - Enigmail 1.4.5 - Exchange 2007/2010 Calendar 3.1.1 - .vcs Support 0.6.4 How reproducible: 100%, multiple restarts and testing different ways. Steps to Reproduce: 1. yum update (upgrade thunderbird/xulrunner) 2. compose mail, type name from eDir 3. hang a core (thunderbird 100%, 0 LDAP results) Actual results: The UI remains responsive so it's not a blocking failure, however no results are returned and we're pegging a core. Expected results: LDAP results as with 16.0.1-1 (normal) Additional info: LDAP is a Novell eDir server, using standard port 389 and has a simple server/port designation. No binddn is used either, it's a very basic setup.
Hm, the only diference between xulrunner-16.0.1-2 and xulrunner-16.0.1-1 is a rebuild with new nss/nspr dependency. Can you test the LDAP search in safe-mode?
I tried various forms of debugging this morning (NSPR_LOG_MODULES) and still couldn't put my finger on the culprit. So, I went through all the various files in my profile (http://kb.mozillazine.org/Files_and_folders_in_the_profile_-_Thunderbird), deleted things like history.mab, ldap-1.mab, removed the LDAP server and prefs and rebuilt everything I could find. Now it's all working as expected. I'll close this as NOTABUG since it appears to have been some sort of corruption in my profile; this profile has been around for a long time (at least Fedora 13) so can't say as to what cruft had gotten up in there.