Closed Bug 422178 Opened 14 years ago Closed 13 years ago
IMAP thread calls docloader from wrong thread [@ JS
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031106 Minefield/3.0b5pre Build Identifier: thunderbird trunk Presently, thunderbird will not fetch mail if the IMAP server certificate is expired. It pops up a warning dialog and then does nothing when the dialog is dismissed. I you then click on a previously fetched (cached) message, thunderbird will crash immediately: http://crash-stats.mozilla.com/report/index/ee4d824c-ef81-11dc-b306-001a4bd43ed6?date=2008-03-11-15 Reproducible: Always Steps to Reproduce: 1. 2. 3.
Thanks, this makes sense. the imap thread is calling the docshell (not thread safe, main thread only) from the imap thread (which will *not* work well). Signature JS_BeginRequest UUID ee4d824c-ef81-11dc-b306-001a4bd43ed6 Time 2008-03-11 08:39:51-07:00 Uptime 0 Product Thunderbird Version 3.0a1pre Build ID 2008031103 OS Linux OS Version 0.0.0 Linux 2.6.25-rc5-00088-g2f44bbb #66 PREEMPT Tue Mar 11 04:51:15 PDT 2008 i686 GNU/Linux CPU x86 CPU Info AuthenticAMD family 1 model 6 stepping 2 Crash Reason SIGSEGV Crash Address 0xb7e33042 Comments Using SSL on IMAP server with expired SSL cert. After I dismiss the warning dialog I try to read a previously dowloaded (cached) message and I immediately see this crash. ( This is on linux. I tried this once on Windows and got no crash.) Crashing Thread Frame Signature Source 0 JS_BeginRequest mozilla/js/src/jsapi.c:871 1 JS_ResumeRequest mozilla/js/src/jsapi.c:988 2 XPCJSContextStack::Pop(JSContext**) mozilla/js/src/xpconnect/src/xpcthreadcontext.cpp:118 3 nsCxPusher::Pop() mozilla/content/base/src/nsContentUtils.cpp:2639 4 nsCxPusher::~nsCxPusher() mozilla/content/base/src/nsContentUtils.cpp:2527 5 nsEventListenerManager::HandleEventSubType(nsListenerStruct*, nsIDOMEventListener*, nsIDOMEvent*, nsISupports*, unsigned int) mozilla/content/events/src/nsEventListenerManager.cpp:1085 6 nsEventListenerManager::HandleEvent(nsPresContext*, nsEvent*, nsIDOMEvent**, nsISupports*, unsigned int, nsEventStatus*) mozilla/content/events/src/nsEventListenerManager.cpp:1186 7 nsEventTargetChainItem::HandleEvent(nsEventChainPostVisitor&, unsigned int) mozilla/content/events/src/nsEventDispatcher.cpp:206 8 nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor&, unsigned int, nsDispatchingCallback*) mozilla/content/events/src/nsEventDispatcher.cpp:237 9 nsEventDispatcher::Dispatch(nsISupports*, nsPresContext*, nsEvent*, nsIDOMEvent*, nsEventStatus*, nsDispatchingCallback*) mozilla/content/events/src/nsEventDispatcher.cpp:479 10 nsDocument::DispatchEventToWindow(nsEvent*) mozilla/content/base/src/nsDocument.cpp:5694 11 nsDocument::OnPageShow(int) mozilla/content/base/src/nsDocument.cpp:5722 12 DocumentViewerImpl::LoadComplete(unsigned int) mozilla/layout/base/nsDocumentViewer.cpp:1007 13 nsDocShell::EndPageLoad(nsIWebProgress*, nsIChannel*, unsigned int) mozilla/docshell/base/nsDocShell.cpp:5030 14 nsWebShell::EndPageLoad(nsIWebProgress*, nsIChannel*, unsigned int) mozilla/docshell/base/nsWebShell.cpp:1013 15 nsDocShell::OnStateChange(nsIWebProgress*, nsIRequest*, unsigned int, unsigned int) mozilla/docshell/base/nsDocShell.cpp:4930 16 nsDocLoader::FireOnStateChange(nsIWebProgress*, nsIRequest*, int, unsigned int) mozilla/uriloader/base/nsDocLoader.cpp:1235 17 nsDocLoader::doStopDocumentLoad(nsIRequest*, unsigned int) mozilla/uriloader/base/nsDocLoader.cpp:858 18 nsDocLoader::DocLoaderIsEmpty() mozilla/uriloader/base/nsDocLoader.cpp:763 19 nsDocLoader::OnStopRequest(nsIRequest*, nsISupports*, unsigned int) mozilla/uriloader/base/nsDocLoader.cpp:679 20 nsLoadGroup::RemoveRequest(nsIRequest*, nsISupports*, unsigned int) mozilla/netwerk/base/src/nsLoadGroup.cpp:688 21 nsImapMockChannel::Close() mozilla/mailnews/imap/src/nsImapProtocol.cpp:7972 22 nsImapProtocol::CloseStreams() mozilla/mailnews/imap/src/nsImapProtocol.cpp:997 23 nsImapProtocol::TellThreadToDie(int) mozilla/mailnews/imap/src/nsImapProtocol.cpp:1086 24 nsImapProtocol::CreateNewLineFromSocket() mozilla/mailnews/imap/src/nsImapProtocol.cpp:4364 25 nsImapProtocol::EstablishServerConnection() mozilla/mailnews/imap/src/nsImapProtocol.cpp:1243 26 nsImapProtocol::ProcessCurrentURL() mozilla/mailnews/imap/src/nsImapProtocol.cpp:1365 27 nsImapProtocol::ImapThreadMainLoop() mozilla/mailnews/imap/src/nsImapProtocol.cpp:1187 28 nsImapProtocol::Run() mozilla/mailnews/imap/src/nsImapProtocol.cpp:959 29 libxpcom_core.so@0x5d0ff 30 libxpcom_core.so@0x28a2c 31 libxpcom_core.so@0x5cda8 32 _pt_root mozilla/nsprpub/pr/src/pthreads/ptthread.c:221 33 libpthread-2.6.1.so@0x518a Show/hide other threads Thread 0 Frame Signature Source 0 @0xb7eee424 1 libX11.so.6.2.0@0x452ce 2 libX11.so.6.2.0@0x3d396 3 libX11.so.6.2.0@0x3de91 4 libX11.so.6.2.0@0x2cedf 5 libgdk-x11-2.0.so.0.1200.5@0x40c5c 6 libgdk-x11-2.0.so.0.1200.5@0x40d40 7 libglib-2.0.so.0.1400.6@0x31a8f 8 libglib-2.0.so.0.1400.6@0x32244 9 libglib-2.0.so.0.1400.6@0x32b36 10 nsBaseAppShell::DoProcessNextNativeEvent(int) mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:133 11 nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, int, unsigned int) mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:252 12 libxpcom_core.so@0x5d09a 13 libxpcom_core.so@0x28a2c 14 nsBaseAppShell::Run() mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:151 15 nsAppStartup::Run() mozilla/toolkit/components/startup/src/nsAppStartup.cpp:181 16 XRE_main mozilla/toolkit/xre/nsAppRunner.cpp:3154 17 main mozilla/mail/app/nsMailApp.cpp:91 18 libc-2.6.1.so@0x15fdb
Assignee: nobody → bienvenu
Severity: major → critical
Component: Mail Window Front End → Networking: IMAP
Product: Thunderbird → Core
QA Contact: front-end → networking.imap
Summary: Expired IMAP server certificate can crash thunderbird → Expired IMAP server certificate can crash thunderbird [@ JS_BeginRequest]
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Expired IMAP server certificate can crash thunderbird [@ JS_BeginRequest] → IMAP thread calls docloader from wrong thread [@ JS_BeginRequest]
for reference, jag does use IMAP and bug 417245 comment 3 is the same problem as comment 0. fixing this is moderately painful: 1. there are a number of messy (mail) classes floating around 2. you can't actually proxy js objects across threads today (this is two bugs, they're filed, they have patches, they've gotten lost, but jst could review them and then the might be slightly less unhappy)
The crash stats I reported in Bug 417245 Comment 0 are from the navigator component of SeaMonkey. Will fixing the mail stuff also fix crashes in Firefox/Minefield and SeaMonkey that don't involve IMAP?
thanks for asking. I decided to check the most basic assumption "there should be no firefox crashers" because any firefox crashers can't be this. sadly, there were, see bugs filed today w/ JS_RestoreFrameChain in the summary. I've reopened yours and redirected it. Sadly, your bug had some other annotations which confused matters, I've tried to migrate them. Note: I've only analyzed all firefox crashers from the past week w/ that one signature, I didn't check seamonkey (which is going to be a bad cross between this bug and firefox) or thunderbird which is mostly going to be this bug. But people are welcome to try, hopefully the logic I used is clear. The simple heuristic is this: if you crash and the crashing thread mentions dom, and you see: Show/hide other threads Thread 0 then you called dom from an illegal thread, because the thread that crashed wasn't thread 0. Determining guilty parties is slightly more painful, but you basically figure out which entry point was used (offhand that's mostly: DNS, Plugins, DOMGlobal[tidy only], Native Event Loop), and then determining which extension/plugin is likely to have reached it. for the actual plugin case this is going to be in the stack, for the extension cases, the basic assumption is that an extension is nice and included a dll/so that enables us to implicate it, you simply skim the modules list for libraries that aren't os/gecko and report all candidates, the next time you hit a similar entry crash you review to see if you have a subset or overlapping set.
Whiteboard: [Thunderbird topcrash]
Nominating for blockingtb3 and taking off 1.9 list.
Since this is a topcrash, blocking 3.0a1 (and final) on it.
It looks to me that this bug is related to #410747. Walter: if you do self builts of TB trunk, can you apply the patch submitted at #410747 and test again?
My email provider finally got a new certificate, so I'd need to simulate the expired cert somehow. Maybe I could patch the code to always return expired? Where would I find that code?
Reassigning to Emre, since he's driving this one.
Assignee: bienvenu → ebirol
Whiteboard: [Thunderbird topcrash] → [believed DUP of bug 410747; needs new patch there to test] [Thunderbird topcrash]
Whiteboard: [believed DUP of bug 410747; needs new patch there to test] [Thunderbird topcrash] → [believed DUP of bug 410747; needs testing with that patch] [Thunderbird topcrash]
If this bug were only about the symptoms described here, it wouldn't block 3.0a1. The main reason it does is because it's a topcrash, which is discussed in more detail in bug 420848. However, as far as steps-to-reproduce go, this is the best we've got. Walter's suggestion sounds like a good one to me. kaie, emre, or anyone else: any thoughts on where to patch this in the code?
Tested (by modifying execution path as Walter has suggested at comment #11) with bug 410747's patch on MAC OS X 10.5.2. It looks like the patch fixes this one as well. Still it's a good idea to test on a Linux machine.
That fix has been landed; resolving this bug.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [believed DUP of bug 410747; needs testing with that patch] [Thunderbird topcrash] → [Thunderbird topcrash]
You need to log in before you can comment on or make changes to this bug.