422178 - IMAP thread calls docloader from wrong thread [@ JS_BeginRequest]

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[walter sheets]

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.

Comment 1

[timeless]

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 	

Comment 5

[timeless]

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)

Comment 6

[Philip Chee]

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?

Comment 7

[timeless]

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.

Comment 8

[Mike Schroepfer]

Nominating for blockingtb3 and taking off 1.9 list.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

Since this is a topcrash, blocking 3.0a1 (and final) on it.

Comment 10

[Emre Birol]

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?

Comment 11

[walter sheets]

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?

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

Reassigning to Emre, since he's driving this one.

Comment 13

[Dan Mosedale (:dmosedale, :dmose)]

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?

Comment 14

[Emre Birol]

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.

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

That fix has been landed; resolving this bug.