Closed Bug 383490 Opened 18 years ago Closed 16 years ago

IMAP accesses weak refs from multiple threads

Categories

(MailNews Core :: Backend, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: bzbarsky, Unassigned)

Details

I ran into this when logging in to an IMAP server: ###!!! ASSERTION: nsWeakReference not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file nsWeakReference.cpp, line 146 The relevant code is: (gdb) frame 6 #6 0xb775a477 in nsImapProtocol::CloseStreams (this=0x8c1d508) at ../../../../mozilla/mailnews/imap/src/nsImapProtocol.cpp:987 987 m_server = nsnull; and m_server used to be an nsImapIncomingServer* inside the weak ref. The stack is: #6 0xb775a477 in nsImapProtocol::CloseStreams (this=0x8c1d508) at ../../../../mozilla/mailnews/imap/src/nsImapProtocol.cpp:987 #7 0xb775a7c5 in nsImapProtocol::TellThreadToDie (this=0x8c1d508, isSafeToClose=0) at ../../../../mozilla/mailnews/imap/src/nsImapProtocol.cpp:1053 #8 0xb7764ce0 in nsImapProtocol::CreateNewLineFromSocket (this=0x8c1d508) at ../../../../mozilla/mailnews/imap/src/nsImapProtocol.cpp:4337 #9 0xb7777ffd in nsImapServerResponseParser::GetNextLineForParser (this=0x8c1d65c, nextLine=0x8c1d664) at ../../../../mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp:125 #10 0xb770dc6c in nsIMAPGenericParser::AdvanceToNextLine (this=0x8c1d65c) at ../../../../mozilla/mailnews/imap/src/nsIMAPGenericParser.cpp:182 #11 0xb770db3a in nsIMAPGenericParser::AdvanceToNextToken (this=0x8c1d65c) at ../../../../mozilla/mailnews/imap/src/nsIMAPGenericParser.cpp:153 #12 0xb77783c5 in nsImapServerResponseParser::ParseIMAPServerResponse (this=0x8c1d65c, currentCommand=0xb161b400 "2 login \"bzbarsky\" \"obezyany\"\r\n", aIgnoreBadAndNOResponses=0) at ../../../../mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp:227 #13 0xb775c6a2 in nsImapProtocol::ParseIMAPandCheckForNewMail (this=0x8c1d508, commandString=0x0, aIgnoreBadAndNOResponses=0) at ../../../../mozilla/mailnews/imap/src/nsImapProtocol.cpp:1576 #14 0xb7766d28 in nsImapProtocol::InsecureLogin (this=0x8c1d508, userName=0xb15eafd4 "bzbarsky", password=@0xb15eb020) at ../../../../mozilla/mailnews/imap/src/nsImapProtocol.cpp:5012 #15 0xb776fc3c in nsImapProtocol::TryToLogon (this=0x8c1d508) at ../../../../mozilla/mailnews/imap/src/nsImapProtocol.cpp:7636 #16 0xb775bb32 in nsImapProtocol::ProcessCurrentURL (this=0x8c1d508) at ../../../../mozilla/mailnews/imap/src/nsImapProtocol.cpp:1417 #17 0xb775ad33 in nsImapProtocol::ImapThreadMainLoop (this=0x8c1d508) at ../../../../mozilla/mailnews/imap/src/nsImapProtocol.cpp:1154 #18 0xb775a120 in nsImapProtocol::Run (this=0x8c1d508) at ../../../../mozilla/mailnews/imap/src/nsImapProtocol.cpp:932
Flags: blocking1.9?
Flags: blocking-thunderbird3?
Regression in 1.9 or older problem?
I don't know. Code around this stuff has changed since 1.8, iirc, but I don't know whether the old code had the same issue.
Per discussion in m.d.a.seamonkey minusing this for 1.9 - if it is a core bug and seamonkey or tbird need this in the 1.9 timeframe please do re-nominate.
Flags: blocking1.9? → blocking1.9-
Product: Core → MailNews Core
This was fixed a while ago, I believe. Closing WFM. There's still some channel stuff that happens when we retry, but I have a patch for that, and it's covered by a different bug - Bug 455966
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: blocking-thunderbird3?
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.