User Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0.1) Gecko/20100101 Firefox/8.0.1 Build ID: 20111120135848 Steps to reproduce: Starting with version 9, I can't no longer establish the LDAP connection; it is however still working fine in version 8. Actual results: After I created a new Directory Server, with same configuration in version 8, going to Offline tab, click on Download Now and it causes a lockup or indicates that the connection to the LDAP server has failed. I've to kill the task to get out of Thunderbird. This has been going on since the first release of version 9,10 and 11. They always behave in the same manner accross the versions. The only version that is still working with LDAP is version 8.

The last update, Dec 9th, fixed the LDAP connections issues in version 9, but it's still broken in version 11 (causing lock-up).

It's also broken in version 10 as well.

I, too am having this problem in 11. User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a1) Gecko/20111210 Thunderbird/11.0a1 Downloading a local copy of the directory doesn't crash Thunderbird for me --- it simply won't connect or download. There is no problem for me in Thunderbird Beta (v9), only the Daily build (v11).

Sorry to be reposting so soon, but to further clarify: Steps to Reproduce: When typing an address into the To: field, the message "LDAP server search problem" appears in the drop-down list of suggestions. Clicking on this message gives the unfortunate error Error code 0x80070057: Unknown error Please contact your System Administrator I hope this helps some.

Just updated Earlybird (v10) and Daily (v11) to Dec 13th update, and LDAP connection is still broken. It won't connect or download; it also causes lock-up in v11 - have to terminate the process from task manager.

so ... works in v8 and 9.0b4 ftp://ftp.mozilla.org/pub/thunderbird/releases/9.0b4/ fails version 9.0b3, 10 and 11. the v10 and v11 failures could be a different bug, if in fact 9.0b2 fails and 9.0b3 works. However, I don't think any ldap specific patches between 9.0b2 and 9.0b3 - bugs fixed in last 6 months https://bugzilla.mozilla.org/buglist.cgi?bug_id=572074%2C126462%2C669151%2C684492%2C693141%2C671827%2C590494%2C706905%2C708577&bug_id_type=anyexact&query_format=advanced&list_id=1885647 does it happen also in thunderbird safe mode? and can you please attach an ldap log using ldap:5,timestamp see https://wiki.mozilla.org/MailNews:Logging Julia, if you are not seeing a hang, then you are likely seeing a different issue, like perhaps bug 609346

This ia all I can get from the log on Thunderbird v10 (Earlybird). I can't get any log for version 11 (Daily), since it hangs. 0[100f140]: nsLDAPOperation::SimpleBind(): called; bindName = 'name@yyy.com'; 0[100f140]: pending operation added; total pending operations now = 1 0[100f140]: nsLDAPConnection::RemovePendingOperation(): operation removed 0[100f140]: nsLDAPConnection::RemovePendingOperation(): operation removed; total pending operations now = 0 0[100f140]: unbinding 0[100f140]: unbound It's still not working after Dec 14 update. and this is the log when it is working -- v9 0[100f140]: nsLDAPOperation::SimpleBind(): called; bindName = 'name@yyy.com'; 0[100f140]: pending operation added; total pending operations now = 1 3652[647a140]: pending operation removed; total pending operations now = 0 0[100f140]: nsLDAPOperation::SearchExt(): called with aBaseDn = 'fn=ContactRoot'; aFilter = '(objectclass=*)'; aAttributes = ; aSizeLimit = 0 0[100f140]: pending operation added; total pending operations now = 1 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000084,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000020,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000000f,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000073,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000033,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000010,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000006d,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000000d,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000013,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000014,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000000b,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000000c,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000074,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000082,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000069,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000016,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000017,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 3652[647a140]: pending operation removed; total pending operations now = 0 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000018,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000000c,fn=Contacts,fn=Public Folders,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000002,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000007e,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000001b,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000001c,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000001d,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000080,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000001e,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000001f,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000022,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000071,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000085,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000004,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000079,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000007,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000027,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000007c,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000002a,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000083,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000003,fn=Contacts,fn=Public Folders,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000006,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000006e,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000030,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000072,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000031,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000034,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000086,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000036,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000076,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000000e,fn=Contacts,fn=Public Folders,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000008,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000038,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000007d,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000006f,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000039,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000007a,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000007b,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000087,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000006b,fn=Contacts,cn=name@yyy.com,fn=ContactRoot' 0[100f140]: unbinding 0[100f140]: unbound

LDAP on Earlybird and Daily are still not working even with Dec 16 update.

(In reply to wisspur from comment #9) > LDAP on Earlybird and Daily are still not working even with Dec 16 update. It is now Dec 19 update, and nothing is resolved.

I believe this is a duplicate of Bug 704984 (the symptom showed up in a different place, but it's the same underlying problem).

(In reply to Irving Reid (:irving) from comment #11) > I believe this is a duplicate of Bug 704984 (the symptom showed up in a > different place, but it's the same underlying problem). Bug 704984 is a different issue, or at least with different cause however the symptoms are identical. Wayne Mery, your report on version is a bit confusing. Could you please find out exactly which Beta 9 version of Thunderbird still works and which is the first that doesn't work? Please also provide download links to the installations to avoid any misses on my side about what build you were testing with. Thanks. PS: TB 9 (official release) works in my test environment well - Replication succeeded and also fills addresses of users from the AD server in To: fields (I have Windows Server 2003).

I dont' actually see the problem. my comment 7 is only an attempt to summarize the reports of others - perhaps not accurately. So others would need to verify the information.

LDAP in Earlybird and Daily still broken with Dec 20 update.

(In reply to wisspur from comment #14) > LDAP in Earlybird and Daily still broken with Dec 20 update. Hi, we know it is still an issue (otherwise we'd likely have marked this as fixed). Please don't comment unless you are adding further information about the bug or the symptoms have changed. What we really need to narrow down is when this regressed. Comparing the various 9.0 betas would be useful, you can download them from here: ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/

(In reply to Mark Banner (:standard8) from comment #15) > (In reply to wisspur from comment #14) > > LDAP in Earlybird and Daily still broken with Dec 20 update. > > Hi, we know it is still an issue (otherwise we'd likely have marked this as > fixed). Please don't comment unless you are adding further information about > the bug or the symptoms have changed. > > What we really need to narrow down is when this regressed. Comparing the > various 9.0 betas would be useful, you can download them from here: > > ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/ I hope you're not going to put the next final version, 10, in the release channel. It is now at 10b2 and the ldap is still broken; I don't want it to update by accident and mess up my good working version 9.0.1 Please get the LDAP working before you put it in the Release Channel! Thx.

(In reply to wisspur from comment #16) > I hope you're not going to put the next final version, 10, in the release > channel. It is now at 10b2 and the ldap is still broken; I don't want it to > update by accident and mess up my good working version 9.0.1 So you reported this bug in comment 0 as broken against Thunderbird 9.0, but you are saying it works in 9.0.1? Or that it always worked in 9.0 as well? Note that we have a known bug in Thunderbird 11 & 12 (bug 704984) so testing there isn't useful at the moment. > Please get the LDAP working before you put it in the Release Channel! I'd love to, but as it stands it works fine for me, which makes it really hard to try and fix. We need more like a clear regression point and clear steps to repeat, there's very little we can do to solve this bug. As I already asked, if you can go through the Thunderbird 9 betas and tell us which ones it is broken in and which ones it isn't, then that would be useful. If TB 8 worked, then starting at TB 9b1 would be a good place to see if there's a regression. It would at least narrow down the possible ranges. Other information that may be useful to us: - Does it happen in safe mode (https://support.mozillamessaging.com/en-US/kb/Safe-Mode) - Are you connecting via ssl? - What type of LDAP server are you connecting to? - Are you using any special LDAP configuration?

(In reply to Mark Banner (:standard8) from comment #17) > (In reply to wisspur from comment #16) > > I hope you're not going to put the next final version, 10, in the release > > channel. It is now at 10b2 and the ldap is still broken; I don't want it to > > update by accident and mess up my good working version 9.0.1 > > So you reported this bug in comment 0 as broken against Thunderbird 9.0, but > you are saying it works in 9.0.1? Or that it always worked in 9.0 as well? > It started working in beta 4 and up to the final release. I believe I reported this incident began with the beta release of version 9. > Note that we have a known bug in Thunderbird 11 & 12 (bug 704984) so testing > there isn't useful at the moment. > > > Please get the LDAP working before you put it in the Release Channel! > > I'd love to, but as it stands it works fine for me, which makes it really > hard to try and fix. We need more like a clear regression point and clear > steps to repeat, there's very little we can do to solve this bug. > > As I already asked, if you can go through the Thunderbird 9 betas and tell > us which ones it is broken in and which ones it isn't, then that would be > useful. If TB 8 worked, then starting at TB 9b1 would be a good place to see > if there's a regression. It would at least narrow down the possible ranges. > > Other information that may be useful to us: > > - Does it happen in safe mode > (https://support.mozillamessaging.com/en-US/kb/Safe-Mode) Yes, it did. LDAP failed to connect even in safe mode. > - Are you connecting via ssl? YES. > - What type of LDAP server are you connecting to? Kerio Connect > - Are you using any special LDAP configuration? No. Use only the hostname and BaseDN: Fn=ContactRoot

> > - Are you using any special LDAP configuration? > No. Use only the hostname, BaseDN: Fn=ContactRoot, and BindDN.

wisspur, please help us analyzing with the following steps: - close thunderbird - setup env vars for logging in your environemnt as: - NSPR_LOG_MODULES = "ldap:5,timestamp" - NSPR_LOG_FILE = "a new file of your choice thunderbird can write to" - start thunderbird - reproduce just and only the issue you describe ; asking for just-and-only since it will minimize the amount of records in the log we'll have to analyze - close thunderbird - submit the file you've set as NSPR_LOG_FILE as an attachment to this bug Thanks!

NSPR_LOG_FILE from TB 9.0.1 (working) and 10b2 (not working)

wisspur, can you please change NSPR_LOG_MODULES to "nspr:5,pipnss:5,ldap:5,timestamp" and retry?

(In reply to Honza Bambas (:mayhemer) from comment #22) > wisspur, can you please change NSPR_LOG_MODULES to > "nspr:5,pipnss:5,ldap:5,timestamp" and retry? Ignore please, I'll trace this down soon my self.

(In reply to Honza Bambas (:mayhemer) from comment #23) > (In reply to Honza Bambas (:mayhemer) from comment #22) > > wisspur, can you please change NSPR_LOG_MODULES to > > "nspr:5,pipnss:5,ldap:5,timestamp" and retry? > > Ignore please, I'll trace this down soon my self. It's ok, I'll do it anyway. It produces the same message as previous log. 2012-01-11 19:34:51.187000 UTC - 0[100f140]: nsLDAPOperation::SimpleBind(): called; bindName = 'me@me.com'; 2012-01-11 19:34:51.218000 UTC - 0[100f140]: pending operation added; total pending operations now = 1 2012-01-11 19:35:02.062000 UTC - 0[100f140]: nsLDAPConnection::RemovePendingOperation(): operation removed 2012-01-11 19:35:02.062000 UTC - 0[100f140]: nsLDAPConnection::RemovePendingOperation(): operation removed; total pending operations now = 0 2012-01-11 19:35:02.062000 UTC - 0[100f140]: unbinding 2012-01-11 19:35:02.062000 UTC - 0[100f140]: unbound

This is a regression from XPCOM proxies removal bug 675221. http://hg.mozilla.org/releases/mozilla-beta/log/886b2220bff9/security/manager/ssl/src/PSMRunnable.cpp We deadlock here (main thread): xul.dll!mozilla::CondVar::Wait(unsigned int interval=4294967295) Line 373 + 0x11 bytes C++ xul.dll!mozilla::Monitor::Wait(unsigned int interval=4294967295) Line 81 C++ xul.dll!mozilla::MonitorAutoLock::Wait(unsigned int interval=4294967295) Line 136 C++ > xul.dll!mozilla::psm::SyncRunnableBase::DispatchToMainThreadAndWait() Line 57 C++ xul.dll!nsNSS_SSLGetClientAuthData(void * arg=0x0a9d7598, PRFileDesc * socket=0x0ac8e180, CERTDistNamesStr * caNames=0x001672fc, CERTCertificateStr * * pRetCert=0x0a9f7a28, SECKEYPrivateKeyStr * * pRetKey=0x0a9f7a2c) Line 2786 + 0xf bytes C++ ssl3.dll!ssl3_HandleCertificateRequest(sslSocketStr * ss=0x0a9f7648, unsigned char * b=0x0ad46289, unsigned int length=0) Line 5582 + 0x32 bytes C ssl3.dll!ssl3_HandleHandshakeMessage(sslSocketStr * ss=0x0a9f7648, unsigned char * b=0x0ad45540, unsigned int length=3401) Line 8671 + 0x11 bytes C ssl3.dll!ssl3_HandleHandshake(sslSocketStr * ss=0x0a9f7648, sslBufferStr * origBuf=0x0a9f78a0) Line 8779 + 0x19 bytes C ssl3.dll!ssl3_HandleRecord(sslSocketStr * ss=0x0a9f7648, SSL3Ciphertext * cText=0x00167460, sslBufferStr * databuf=0x0a9f78a0) Line 9118 + 0xd bytes C ssl3.dll!ssl3_GatherCompleteHandshake(sslSocketStr * ss=0x0a9f7648, int flags=0) Line 209 + 0x17 bytes C ssl3.dll!ssl_GatherRecord1stHandshake(sslSocketStr * ss=0x0a9f7648) Line 1258 + 0xb bytes C ssl3.dll!ssl_Do1stHandshake(sslSocketStr * ss=0x0a9f7648) Line 153 + 0xf bytes C ssl3.dll!ssl_SecureSend(sslSocketStr * ss=0x0a9f7648, const unsigned char * buf=0x06f80fb4, int len=43, int flags=0) Line 1229 + 0x9 bytes C ssl3.dll!ssl_Send(PRFileDesc * fd=0x0ac8e180, const void * buf=0x06f80fb4, int len=43, int flags=0, unsigned int timeout=10000) Line 1649 + 0x1b bytes C xul.dll!nsSSLThread::requestWrite(nsNSSSocketInfo * si=0x0a9d7598, const void * buf=0x06f80fb4, int amount=43, unsigned int timeout=10000) Line 790 + 0x1c bytes C++ xul.dll!PSMSend(PRFileDesc * fd=0x0ac31f20, const void * buf=0x06f80fb4, int amount=43, int flags=0, unsigned int timeout=10000) Line 2050 + 0x15 bytes C++ nspr4.dll!PR_Send(PRFileDesc * fd=0x0ac31f20, const void * buf=0x06f80fb4, int amount=43, int flags=0, unsigned int timeout=10000) Line 226 + 0x1e bytes C nsldappr32v60.dll!prldap_write(int s=1, const void * buf=0x06f80fb4, int len=43, lextiof_socket_private * socketarg=0x0a164e18) Line 218 + 0x1a bytes C nsldap32v60.dll!ber_flush(sockbuf * sb=0x074f9128, berelement * ber=0x06f80e88, int freeit=0) Line 439 + 0x26 bytes C nsldap32v60.dll!nsldapi_send_ber_message(ldap * ld=0x06fd71f0, sockbuf * sb=0x074f9128, berelement * ber=0x06f80e88, int freeit=0, int epipe_handler=1) Line 473 + 0x11 bytes C nsldap32v60.dll!nsldapi_send_server_request(ldap * ld=0x06fd71f0, berelement * ber=0x06f80e88, int msgid=1, ldapreq * parentreq=0x00000000, ldap_server * srvlist=0x00000000, ldap_conn * lc=0x09761e50, char * bindreqdn=0x0aae86a0, int bind=0) Line 342 + 0x17 bytes C nsldap32v60.dll!nsldapi_send_initial_request(ldap * ld=0x06fd71f0, int msgid=1, unsigned long msgtype=96, char * dn=0x0ac89a60, berelement * ber=0x06f80e88) Line 148 + 0x2b bytes C nsldap32v60.dll!simple_bind_nolock(ldap * ld=0x06fd71f0, const char * dn=0x0ac89a60, const char * passwd=0x0aae4168, int unlock_permitted=1) Line 153 + 0x17 bytes C nsldap32v60.dll!ldap_simple_bind(ldap * ld=0x06fd71f0, const char * dn=0x0ac89a60, const char * passwd=0x0aae4168) Line 82 + 0x13 bytes C xul.dll!nsLDAPOperation::SimpleBind(const nsACString_internal & passwd={...}) Line 322 + 0x30 bytes C++ xul.dll!nsAbLDAPListenerBase::OnLDAPInit(nsILDAPConnection * aConn=0x0a063fc0, unsigned int aStatus=0) Line 302 + 0x35 bytes C++ xul.dll!nsLDAPConnection::OnLookupComplete(nsICancelable * aRequest=0x0750a784, nsIDNSRecord * aRecord=0x06307ed0, unsigned int aStatus=0) Line 664 C++ xul.dll!`anonymous namespace'::DNSListenerProxy::OnLookupCompleteRunnable::Run() Line 528 C++ The fix is already written in bug 704984 (or better bug 712363). Attachment 583957 [details] [diff] fixes the issue.

This is not actually a duplicate of bug 712363 since this is caused by only a subset of causes from that bug. Also that bug is not intended (not valid) to land on mozilla-beta.

Hi, I don't know if this bug has been fixed in the unsigned win32-10.0b3 or not, released on Jan-11 15:33. I just test it out and the LDAP is still broken. Just a FYI. http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/10.0b3-candidates/build1/unsigned/win32/en-US/

FYI. LDAP on version 10.0b3, released on 12-Jan-2012 06:09, is still broken. http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/10.0b3-candidates/build1/win32/en-US/

wisspur, this bug is not fixed. There is even no try build you could to test. The work necessary to be done will probably be all done in bug 712363, so CC on it and watch its progress.

[Approval Request Comment] Regression caused by (bug #): bug 675221 User impact if declined: Thunderbird deadlock while accessing LDAP server (usually during address auto-complete in New mail window) Testing completed (on m-c, etc.): Just manual test of comm-beta with this patch applied over mozilla code with an OCSP'ed secured LDAP server on WinServer2003 Risk to taking this patch (and alternatives if risky): First I need to test what impact this have on Firefox it self ; however all networking in Firefox is made on the socket transport service thread and none is made on the main thread (that would lead to similar bug like this one particular) ; any risk is then small / For absolute safety we could add #ifdef MOZ_THUNDERBIRD around the new code. Try run (based on the current mozilla-beta default changeset): https://tbpl.mozilla.org/?tree=Try&rev=244a25d1fd6b This patch is not sufficient for current Aurora and Nightly code and has to land only on mozilla-beta.

This doesn't affect Firefox. It should only land in comm-beta, comm-aurora, mozilla-central, and comm-central, AFAICT. I don't know if we have any procedures for comm-* taking private patches to mozilla/* though. (This is not so much of an issue for this particular patch, as it would be for the patches in bug 712363, which are higher risk.

I'd really like to land this in mozilla-beta if possible - even though it doesn't affect Firefox. If we don't land it in mozilla-beta, then I expect I will need to create a relbranch for each release of TB 10, unfortunately TB 10 is also expected to be our ESR release, and hence relbranching would be expensive. If we're not comfortable with landing, then I'd go the ifdef route so that we could land that without a relbranch.

This is the same patch as the other one on this bug, but has ifdefs for SeaMonkey & Thunderbird to build the new code, and leave Firefox alone. Honza, could you just look at this to make sure I've got it right. I did the minimum necessary so that we can see that Firefox is left unchanged (rather than optimising what was being ifdeffed). For approval: this has no affect on Firefox, and hence turns into a Thunderbird/SeaMonkey only bug.

(btw Alex said over direct email that he'd prefer the ifdef one)

Comment on attachment 590790 [details] [diff] [review] Same patch, but ifdef Thunderbird and SeaMonkey If Honza's not about, maybe Brian can give this a quick check.

Using bsmith's patch () I'm getting an error when I try to do a basic search of an LDAPS server in the address book window (running with NSPR_LOG_MODULES=ldap:5,timestamp) This patch is meant to stand alone, right? I applied it over a clean copy of this morning's trunk, is that OK or should I be on the 9 or 10 branch? Also, I'd sure like to figure out where the actual problem is so that I can cause it to return a more useful diagnostic than 'Error'... 2012-01-23 19:24:17.458003 UTC - 1886665920[100319260]: nsLDAPOperation::SimpleBind(): called; bindName = 'mail=ireid@mozilla.com,o=com,dc=mozilla'; 2012-01-23 19:24:26.650579 UTC - 1886665920[100319260]: ###!!! ASSERTION: nsAbLDAPMessageBase::OnLDAPInit(): failed to perform bind operation: 'Error', file /Users/ireid/tbird/comm-central/mailnews/addrbook/src/nsAbLDAPListenerBase.cpp, line 305 ###!!! ASSERTION: nsAbLDAPMessageBase::OnLDAPInit(): failed to perform bind operation: 'Error', file /Users/ireid/tbird/comm-central/mailnews/addrbook/src/nsAbLDAPListenerBase.cpp, line 305 This was reliably failing for me every time I tried to search. I restarted my TB with the extended logging settings from an earlier comment on this bug, and this time the trace shows a failing bind attempt followed by a successful bind and the search worked: 2012-01-23 19:31:45.294821 UTC - 1886665920[100319260]: nsLDAPOperation::SimpleBind(): called; bindName = 'mail=ireid@mozilla.com,o=com,dc=mozilla'; 2012-01-23 19:31:45.371331 UTC - 1886665920[100319260]: [11dd1d220] Socket set up Current language: auto; currently c 2012-01-23 19:31:52.147409 UTC - 1886665920[100319260]: [124524040] starting AuthCertificateHook 2012-01-23 19:31:52.147548 UTC - 646451200[1267f7a40]: [1267f7920] SSLServerCertVerificationJob::Run 2012-01-23 19:31:52.150429 UTC - 646451200[1267f7a40]: AuthCertificate setting NEW cert 11a8b34a0 2012-01-23 19:31:52.238980 UTC - 1886665920[100319260]: [11dd1d220] wrote -1 bytes 2012-01-23 19:31:52.239171 UTC - 1886665920[100319260]: ###!!! ASSERTION: nsAbLDAPMessageBase::OnLDAPInit(): failed to perform bind operation: 'Error', file /Users/ireid/tbird/comm-central/mailnews/addrbook/src/nsAbLDAPListenerBase.cpp, line 305 ###!!! ASSERTION: nsAbLDAPMessageBase::OnLDAPInit(): failed to perform bind operation: 'Error', file /Users/ireid/tbird/comm-central/mailnews/addrbook/src/nsAbLDAPListenerBase.cpp, line 305 2012-01-23 19:31:52.244199 UTC - 411594752[1003194a0]: HandshakeCallback KEEPING cert 11a8b34a0 2012-01-23 19:31:52.244248 UTC - 411594752[1003194a0]: [11890cbb0] poll SSL socket using lower 5 2012-01-23 19:31:52.244258 UTC - 411594752[1003194a0]: [11890cbb0] poll SSL socket returned 5 2012-01-23 19:31:52.244267 UTC - 411594752[1003194a0]: [11c272730] poll SSL socket using lower 5 2012-01-23 19:31:52.244274 UTC - 411594752[1003194a0]: [11c272730] poll SSL socket returned 5 2012-01-23 19:31:52.244282 UTC - 411594752[1003194a0]: [126596100] poll SSL socket using lower 5 2012-01-23 19:31:52.244289 UTC - 411594752[1003194a0]: [126596100] poll SSL socket returned 5 2012-01-23 19:31:52.244297 UTC - 411594752[1003194a0]: [126e415e0] poll SSL socket using lower 5 2012-01-23 19:31:52.244304 UTC - 411594752[1003194a0]: [126e415e0] poll SSL socket returned 5 2012-01-23 19:31:52.244313 UTC - 411594752[1003194a0]: [126a74550] poll SSL socket using lower 5 2012-01-23 19:31:52.244319 UTC - 411594752[1003194a0]: [126a74550] poll SSL socket returned 5 2012-01-23 19:31:52.290223 UTC - 1886665920[100319260]: nsLDAPOperation::SimpleBind(): called; bindName = 'mail=ireid@mozilla.com,o=com,dc=mozilla'; 2012-01-23 19:31:52.365465 UTC - 1886665920[100319260]: [124d1a0a0] Socket set up 2012-01-23 19:31:56.532522 UTC - 1886665920[100319260]: HandshakeCallback using NEW cert 11a8b3bc0 2012-01-23 19:31:56.532593 UTC - 1886665920[100319260]: [124d1a0a0] wrote 65 bytes 2012-01-23 19:31:56.532804 UTC - 1886665920[100319260]: pending operation added; total pending operations now = 1 2012-01-23 19:31:56.532862 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:31:56.532883 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:31:56.532907 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:31:56.532914 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:31:56.532927 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:31:56.532933 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:31:56.532949 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:31:56.532955 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:31:56.532968 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:31:56.532973 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:31:56.587824 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:31:56.587838 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:31:56.587852 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:31:56.587858 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:31:56.587871 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:31:56.587876 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:31:56.587889 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:31:56.587895 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:31:56.587908 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:31:56.587913 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:31:56.587926 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:31:56.631834 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:31:56.631936 UTC - 1165111296[123dfe700]: [124d1a0a0] read 14 bytes 2012-01-23 19:31:56.632011 UTC - 1165111296[123dfe700]: InvokeMessageCallback entered 2012-01-23 19:31:56.632050 UTC - 1165111296[123dfe700]: pending operation removed; total pending operations now = 0 2012-01-23 19:31:56.632171 UTC - 1886665920[100319260]: nsLDAPOperation::SearchExt(): called with aBaseDn = 'dc=mozilla'; aFilter = '(|(mail=*ireid*)(cn=*ireid*)(givenName=*ireid*)(sn=*ireid*))'; aAttributes = birthday,o,company,mail,modifytimestamp,mozillaHomeCountryName,mozillaUseHtmlMail,xmozillausehtmlmail,mozillaCustom2,custom2,mozillaCustom4,custom4,ou,department,departmentnumber,orgunit,mobile,cellphone,carphone,telephoneNumber,title,mozillaCustom1,custom1,sn,surname,mozillaNickname,xmozillanickname,mozillaWorkUrl,workurl,labeledURI,facsimiletelephonenumber,fax,mozillaSecondEmail,xmozillasecondemail,nsAIMid,nscpaimscreenname,street,streetaddress,postOfficeBox,l,locality,homePhone,mozillaHomeUrl,homeurl,mozillaHomeStreet,givenName,mozillaHomePostalCode,mozillaHomeLocalityName,mozillaCustom3,custom3,mozillaWorkStreet2,mozillaHomeStreet2,postalCode,zip,c,countryname,pager,pagerphone,mozillaHomeState,st,region,description,notes,birthyear,birthmonth,cn,commonname,objectClass; aSizeLimit = 100 2012-01-23 19:32:22.108167 UTC - 1886665920[100319260]: [124d1a0a0] wrote 963 bytes 2012-01-23 19:32:22.108318 UTC - 1886665920[100319260]: pending operation added; total pending operations now = 1 2012-01-23 19:32:22.108363 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.108375 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.108408 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.108417 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.108443 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.108452 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.108474 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.108482 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.108504 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.108512 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.129092 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.129106 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.129122 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.129127 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.129140 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.129146 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.129158 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.129164 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.129177 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.129182 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.129195 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185658 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.185710 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185716 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.185730 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185735 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.185748 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185753 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.185766 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185772 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.185785 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185790 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.185802 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185808 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.185821 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185826 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.185839 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185886 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.185915 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185922 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.185936 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185941 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.185954 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185959 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.185972 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185977 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.185990 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.185995 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.188405 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.188414 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.188429 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.188434 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.188448 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.188453 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.188466 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.188472 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.188485 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.188490 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.216643 UTC - 1165111296[123dfe700]: [124d1a0a0] read 398 bytes 2012-01-23 19:32:22.216675 UTC - 1165111296[123dfe700]: InvokeMessageCallback entered 2012-01-23 19:32:22.216727 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket using lower 1 2012-01-23 19:32:22.216737 UTC - 1165111296[123dfe700]: [124d1a0a0] poll SSL socket returned 1 2012-01-23 19:32:22.216797 UTC - 1165111296[123dfe700]: [124d1a0a0] read 14 bytes 2012-01-23 19:32:22.216836 UTC - 1165111296[123dfe700]: InvokeMessageCallback entered 2012-01-23 19:32:22.216864 UTC - 1165111296[123dfe700]: pending operation removed; total pending operations now = 0 2012-01-23 19:32:22.218065 UTC - 1886665920[100319260]: nsLDAPMessage::GetValues(): called with aAttr = 'mail' 2012-01-23 19:32:22.218277 UTC - 1886665920[100319260]: nsLDAPMessage::GetValues(): called with aAttr = 'modifytimestamp' 2012-01-23 19:32:22.218714 UTC - 1886665920[100319260]: nsLDAPMessage::GetValues(): called with aAttr = 'mobile' 2012-01-23 19:32:22.218901 UTC - 1886665920[100319260]: nsLDAPMessage::GetValues(): called with aAttr = 'title' 2012-01-23 19:32:22.219097 UTC - 1886665920[100319260]: nsLDAPMessage::GetValues(): called with aAttr = 'sn' 2012-01-23 19:32:22.219743 UTC - 1886665920[100319260]: nsLDAPMessage::GetValues(): called with aAttr = 'givenname' 2012-01-23 19:32:22.220330 UTC - 1886665920[100319260]: nsLDAPMessage::GetValues(): called with aAttr = 'description' 2012-01-23 19:32:22.220556 UTC - 1886665920[100319260]: nsLDAPMessage::GetValues(): called with aAttr = 'cn' 2012-01-23 19:32:22.220648 UTC - 1886665920[100319260]: nsLDAPMessage::GetDn(): dn = 'mail=ireid@mozilla.com,o=com,dc=mozilla' 2012-01-23 19:32:22.220723 UTC - 1886665920[100319260]: nsLDAPMessage::GetValues(): called with aAttr = 'objectClass'

I meant to link to the attachment in the previous comment: https://bugzilla.mozilla.org/attachment.cgi?id=590510 Also, having succeeded once, I'm back to seeing searches fail with the same error every time.

(In reply to Irving Reid (:irving) from comment #36) > 2012-01-23 19:31:52.150429 UTC - 646451200[1267f7a40]: AuthCertificate > setting NEW cert 11a8b34a0 This basically means that AuthCertificate(Hook) is going to return SECSuccess to let the connection continue > 2012-01-23 19:31:52.238980 UTC - 1886665920[100319260]: [11dd1d220] wrote -1 > bytes But, PR_Write/PR_Send failed anyway. We need to know the value of PR_GetError() at this point.

The patch is only for TB 10. For trunk you need the rest of the patches on the other bug.

Comment on attachment 590790 [details] [diff] [review] Same patch, but ifdef Thunderbird and SeaMonkey I recommend that we just take the original patch. The original patch is very safe to take for mozilla-beta. Actually, it is probably safer than what is on mozilla-beta right now--that is, it is a good change even for Firefox. In fact, Honza had recommended me to do things this way when I originally wrote the feature.

Comment on attachment 590510 [details] [diff] [review] Make SyncRunnableBase work without deadlocking when run on the main thread [v2] [by Brian Smith, from bug 712363] [Triage Comment] Upon Brian and Honza's recommendation, and given the low-risk nature of this bug, let's take this for beta 6. There should be no effect on FF10.

Comment on attachment 590790 [details] [diff] [review] Same patch, but ifdef Thunderbird and SeaMonkey Review of attachment 590790 [details] [diff] [review]: ----------------------------------------------------------------- For me both patches are OK. Let drives pick the one they like more. I prefer the NOT IFDEF'ed one a bit more. If landed the IFDEF'ed, then I'd be glad to land on m-c a non ifdefed one asap.

Comment on attachment 590790 [details] [diff] [review] Same patch, but ifdef Thunderbird and SeaMonkey Hmm.. I didn't want to change the approval flags and I wanted to add r+.

OK, finally got this built on TB 10 (Beta) and it's working OK, though I did notice one quirk - at one point, as I was changing what was typed in the To: address box, TB threw a couple of assertion fail messages: ###!!! ASSERTION: We don't know what went wrong with the ldap operation: 'Error', file /Users/ireid/tbird/comm-beta/ldap/xpcom/src/nsLDAPConnection.cpp, line 704 ###!!! ASSERTION: Using observer service off the main thread!: 'Error', file /Users/ireid/tbird/comm-beta/mozilla/xpcom/ds/nsObserverService.cpp, line 143 WARNING: NS_ENSURE_TRUE(mThread != PR_GetCurrentThread()) failed: file /Users/ireid/tbird/comm-beta/mozilla/xpcom/threads/nsThread.cpp, line 466 ###!!! ASSERTION: Failed to shutdown thread cleanly: '!mThread || NS_SUCCEEDED(mThread->Shutdown())', file /Users/ireid/tbird/comm-beta/ldap/xpcom/src/nsLDAPConnection.cpp, line 241 (the middle one about the observer service may be unrelated; I've seen similar messages at other times but haven't investigated) It appears to happen pretty reliably if I backspace medium-quickly (like 0.25 seconds or so) after entering an address prefix, like: bsmi (autocomplete suggestions show up) <backspace><backspace><backspace> If I time it so I hit backspace just before the next set of autocomplete results show, I get the assertion failure. TB recovers and displays the correct autocomplete for whatever is left in the address box, so I'm guessing that we're just not quite doing the right thing to cancel an in-progress search before we start the next one. ... Went hunting through bugzilla to see if anyone had reported the "We don't know what went wrong" assertion, and when I came back to my TB client, my autocomplete is now completely broken with: ###!!! ASSERTION: nsLDAPAutoCompleteSession::DoTask(): couldn't initialize LDAP operation: 'Error', file /Users/ireid/tbird/comm-beta/mailnews/addrbook/src/nsLDAPAutoCompleteSession.cpp, line 576 Not sure whether it's related to the patch in this bug or to the autocomplete/backspace, or both... Off to do some more testing.

This didn't end up landing in time for FF10 beta 6. Mark will resolve on a separate branch for TB10, and we'll take this patch for the first FF10 ESR to prevent TB from needing to land this for each ESR release.

I've just landed this on a relbranch for Thunderbird/SeaMonkey: http://hg.mozilla.org/releases/mozilla-beta/rev/87215b657b0c Flagging as fixed for 10, but leaving open until we get this on the ESR line.

Just tested the TB 10.0b5 (25-Jan-2012 05:20), and the LDAP is still not working.

Sad to report that the LDAP in this ESR version failed. For now, it seems the TB 9.0.1 is the most stable version. http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/10.0esr-candidates/build1/win32/en-US/

Then unfortunately we still don't know what your issue is, I think we're probably at the stage where we need to have details of your server and specifics of what's happening with your connection.

(In reply to Mark Banner (:standard8) from comment #49) > Then unfortunately we still don't know what your issue is, I think we're > probably at the stage where we need to have details of your server and > specifics of what's happening with your connection. I've had answered your questions above regarding the type of my server before. > Other information that may be useful to us: > > - Does it happen in safe mode > (https://support.mozillamessaging.com/en-US/kb/Safe-Mode) Yes, it did. LDAP failed to connect even in safe mode. > - Are you connecting via ssl? YES. > - What type of LDAP server are you connecting to? Kerio Connect > - Are you using any special LDAP configuration? No. Use only the hostname, BaseDN: Fn=ContactRoot, and BindDN It's working well on TB 9.0.1 and it's not working on version 10, then the question is whether it was the problems with the LDAP server I was connecting to or the coding problems existed in TB 10.0? You decide :-)

(In reply to wisspur from comment #48) > Sad to report that the LDAP in this ESR version failed. What exactly means "failed" ? Is it a crash or hang of TB 10 or it just fails to replicate or auto-complete?

(In reply to wisspur from comment #48) > Sad to report that the LDAP in this ESR version failed. For now, it seems > the TB 9.0.1 is the most stable version. > > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/10.0esr- > candidates/build1/win32/en-US/ A debug build using the source code for the 10 esr build1 works for me well. No deadlocks, accessing a secure LDAP with OCSP'ed cert works as expected (success when the CA is trusted, failure when not trusted). This really is a different issue. But helped to identify a different one. For now closing this bug for consistency and opening a new one for the current issue as reported in comment 48.

Reported bug 723551 on the issue from comment 48.

(In reply to Honza Bambas (:mayhemer) from comment #51) > (In reply to wisspur from comment #48) > > Sad to report that the LDAP in this ESR version failed. > > What exactly means "failed" ? Is it a crash or hang of TB 10 or it just > fails to replicate or auto-complete Replication failed!

(In reply to Honza Bambas (:mayhemer) from comment #52) > (In reply to wisspur from comment #48) > > Sad to report that the LDAP in this ESR version failed. For now, it seems > > the TB 9.0.1 is the most stable version. > > > > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/10.0esr- > > candidates/build1/win32/en-US/ > > A debug build using the source code for the 10 esr build1 works for me well. > No deadlocks, accessing a secure LDAP with OCSP'ed cert works as expected > (success when the CA is trusted, failure when not trusted). > One thing is worth mentioning that my mail server is using self-signed certificate. Does it have anything to do with this LDAP replication failure? It still works well on TB 9.0.1

Please land on mozilla-esr10 as soon as possible. For more information on the landing process, please see https://wiki.mozilla.org/Release_Management/ESR_Landing_Process

Alex, are you sure this is the right bug? Why are we to land this patch on ESR?

(In reply to Brian Smith (:bsmith) from comment #57) > Alex, are you sure this is the right bug? Why are we to land this patch on > ESR? This is the patch we shipped with TB 10 to fix an issue there. The other SSL patches aren't needed until TB 11.

Checked in for ESR: https://hg.mozilla.org/releases/mozilla-esr10/rev/29b3fbdf018e

Untracking from QA Firefox Desktop verifications