Closed Bug 401275 Opened 17 years ago Closed 13 years ago

Crash calling StopMeteors on the IMAP thread

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: neil, Assigned: Bienvenu)

Details

(Keywords: crash)

The crash actually happens after some threadsafety assertions. Sorry the stack trace isn't very good, but I was using WinDbg rather than VC8: caps!nsScriptSecurityManager::doGetObjectPrincipal+0x11a caps!nsScriptSecurityManager::GetFunctionObjectPrincipal+0xcd caps!nsScriptSecurityManager::GetFramePrincipal+0x8b caps!nsScriptSecurityManager::GetPrincipalAndFrame+0x8a caps!nsScriptSecurityManager::GetSubjectPrincipal+0x3e caps!nsScriptSecurityManager::CheckPropertyAccessImpl+0x1c caps!nsScriptSecurityManager::CheckPropertyAccess+0x29 gklayout!nsDOMClassInfo::doCheckPropertyAccess+0x1db gklayout!nsWindowSH::GetProperty+0x35e xpc3250!XPC_WN_Helper_GetProperty+0x91 js3250!js_NativeGet+0x2b0 js3250!js_Interpret+0xc25e js3250!js_Invoke+0xbc2 js3250!js_InternalInvoke+0x118 js3250!JS_CallFunctionValue+0x23 xpc3250!nsXPCWrappedJSClass::CallQueryInterfaceOnJSObject+0x1ad xpc3250!nsXPCWrappedJSClass::GetRootJSObject+0x1e xpc3250!nsXPCWrappedJS::GetNewOrUsed+0x97 xpc3250!nsXPCWrappedJSClass::DelegatedQueryInterface+0x375 xpc3250!nsXPCWrappedJS::QueryInterface+0x133 xpcom_core!nsWeakReference::QueryReferent+0x26 xpcom_core!nsQueryReferent::operator()+0x2f msgbase!nsCOMPtr<nsIMsgStatusFeedback>::assign_from_helper+0x1a msgbase!nsCOMPtr<nsIMsgStatusFeedback>::nsCOMPtr<nsIMsgStatusFeedback>+0x34 msgbase!nsMsgStatusFeedback::StopMeteors+0x29 msgbsutl!nsMsgMailNewsUrl::SetUrlState+0x106 msgimap!nsImapMailFolder::SetUrlState+0xb4 msgimap!nsImapMockChannel::NotifyStartEndReadFromCache+0xe7 msgimap!nsImapMockChannel::Close+0x19 msgimap!nsImapProtocol::CloseStreams+0xc0 msgimap!nsImapProtocol::TellThreadToDie+0x213 msgimap!nsImapProtocol::CreateNewLineFromSocket+0x277 msgimap!nsImapServerResponseParser::GetNextLineForParser+0x1e msgimap!nsIMAPGenericParser::AdvanceToNextLine+0x62 msgimap!nsIMAPGenericParser::AdvanceToNextToken+0x21 msgimap!nsImapServerResponseParser::ParseIMAPServerResponse+0x1f7 msgimap!nsImapProtocol::ParseIMAPandCheckForNewMail+0x58 msgimap!nsImapProtocol::SelectMailbox+0xd6 msgimap!nsImapProtocol::ProcessSelectedStateURL+0x305 msgimap!nsImapProtocol::ProcessCurrentURL+0xa71 msgimap!nsImapProtocol::ImapThreadMainLoop+0x107 msgimap!nsImapProtocol::Run+0xb9 xpcom_core!nsThread::ProcessNextEvent+0x19c xpcom_core!NS_ProcessNextEvent_P+0x54 xpcom_core!nsThread::ThreadFunc+0xca nspr4!_PR_NativeRunThread+0xd9 nspr4!pr_root+0x17 MSVCR71D!_beginthreadex+0x196 kernel32!BaseThreadStart+0x37
I believe the issue is that we shouldn't be closing the stream from the imap thread - the streams expect to be closed on the UI thread.
is nsScriptSecurityManager::doGetObjectPrincipal the top of stack?
Severity: normal → critical
Product: Core → MailNews Core
(In reply to comment #1) > I believe the issue is that we shouldn't be closing the stream from the imap > thread - the streams expect to be closed on the UI thread. bienvenu, perhaps fixed by bug 476960 or one of the other recent imap changes? (In reply to comment #0) > The crash actually happens after some threadsafety assertions. one was fixed in bug 330273
yes, bug 476960 is about making sure we do the right things on the right thread(s).
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.