373895 - Crash when moving from partly displayed large IMAP message to another IMAP folder [@ nsImapProtocol::SetupWithUrl]

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: IMAP, defect)

Description

[William Rose]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: version 2.0pre (20070312) exe version 1.8.20070.31203

If I am browsing my emails and switch through the four IMAP profiles I have set up, I sometimes get crashes.  I have narrowed this down to a specific set of messages, which are all very large ~10MB.  These messages were (for a time) the most recent in one of the profile inboxes, and would automatically begin to display in the preview panel on selecting that profile's inbox.  Moving quickly to another inbox or mail folder (even in the same profile) would cause the crash.

Reproducible: Always

Steps to Reproduce:
1. Have a large email (e.g. ~10MB) that takes a few seconds to display completely (e.g. due to lots of attachments).
2. Select this message in the folder window and look to Preview Pane to see message partly render.
3. Click on another folder from the tree while the message is rendering.
Actual Results:  
Thunderbird crashes, bringing up the Talkback screen and the Microsoft error reporting screen.  Talkback IDs for example crashes are TB30221519Z and TB30221498W.

Expected Results:  
No crash -- the message either finishes rendering and the pane switches to the new mail box or it switches immediately.

I have previously considered reporting this bug but found I could not recreate it in the 3.0 branch nightlies from a few weeks ago, not realising that the 2.0 branch was actually closer to release :-).  I'm raising it now as it's cropping up in 2.0pre and may be fixable for that release too.

I tried to create a log file as recommended at http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap (using IMAP:5) and found that I could not replicate the bug as the logging seemed to slow down the loading process and I was never able to interrupt the message render.  I suppose this points to problems after the data load is loaded from the network, which is normally pretty quick and probably done by the time I switch folders.  Please let me know if a log at a lower level (e.g 3, 4) would be helpful and I will try to capture the bug at these levels.  Otherwise there are the talkback IDs above.

My mail server runs on a machine on the local LAN (100Mbit ethernet) and messages normally display fairly quickly, so this has not been a problem until I had a large email as the most recent in an inbox.  The mail server is running Cyrus IMAPD 2.2 (2.2.12-4ubuntu1 Ubuntu 6.06 package) on Intel Core 2 Duo server and Postfix 2.2 (2.2.10-1ubuntu0.1 package).

The computer running Thunderbird is a Dell Inspiron 6400 2.0GHz Core 2 Duo with 2GB RAM, and Thunderbird is otherwise completely stable.

Comment 1

[Magnus Melin [:mkmelin]]

Same stack, both stacks are

e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 821
Stack Trace 	
nsImapProtocol::SetupWithUrl  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 821]
nsImapProtocol::LoadImapUrl  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 1694]
nsImapIncomingServer::GetImapConnectionAndLoadUrl  [mozilla/mailnews/imap/src/nsImapIncomingServer.cpp, line 458]
nsImapMockChannel::ReadFromImapConnection  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 8445]
nsImapMockChannel::OnCacheEntryAvailable  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 8271]
XPTC_InvokeByIndex  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102]
EventHandler  [mozilla/xpcom/proxy/src/nsProxyEvent.cpp, line 561]
0x778b0c24
nsHTMLTableRowElement::nsHTMLTableRowElement  [mozilla/content/html/content/src/nsHTMLTableRowElement.cpp, line 122]
0x6d3be808

Comment 2

[Fernando Hartmann]

This happen to me too, to me its no necessary to change the imap folder, it happens changing quick to other message in the same folder while the "big" message is loaded in the preview pane.
My TB version is.. version 2.0.0.6 (20070728)

Comment 3

[Wayne Mery (:wsmwk)]

nsImapProtocol::SetupWithUrl will be top 10 crasher once 2.0.0.7 distributes.
no crashes found for trunk, not even in top 10 stack frames.
no dupe bugs
confirming, but needs more diagnosis

several talkback reports with same stack
TB36828940 trying to open mail with multiple mail attachments and files
TB36758719 Selecting entire conversation thread on MS Exch.2003 IMAP4/ssl server
TB36757542 i was using alt tab
TB36768759 opening e-mail with attachments


Fernando, is this easy for you to reproduce?
talkback id?

Comment 4

[Fernando Hartmann]

Yes, it's easy, I just reproduced the crash now and submitted by talkback. 
ID TB36845861Y

Comment 5

[Wayne Mery (:wsmwk)]

does (fixed) bug 261083 help?   
bug 274981 "Thunderbird crashes when deleting mail form IMAP inbox - [@ nsImapProtocol::SetupWithUrl]" was duped to it.


(In reply to comment #4)
> Yes, it's easy, I just reproduced the crash now and submitted by talkback. 
> ID TB36845861Y

top of stack is nsPipe::AdvanceWriteCursor (with relatively low incident count in talkback) so perhaps not same problem as reporter.  Suggest you file a new bug.
nsPipe::AdvanceWriteCursor  [mozilla/xpcom/io/nsPipe3.cpp, line 518]
nsPipeOutputStream::WriteSegments  [mozilla/xpcom/io/nsPipe3.cpp, line 1072]
nsPipeOutputStream::Write  [mozilla/xpcom/io/nsPipe3.cpp, line 1145]
nsImapProtocol::HandleMessageDownLoadLine  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 3488]
nsImapServerResponseParser::msg_fetch_literal  [mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp, line 2967]
nsImapServerResponseParser::msg_fetch_content  [mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp, line 2068]
nsImapServerResponseParser::msg_fetch  [mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp, line 1197]
0x046206e8
0x02bb4fc4 

Comment 6

[Fernando Hartmann]

There are times that I do the same steps and the stack trace is similar to this bug stack, like my other talkback TB35363208W, this was generated with a similar steps...
Switching between emails that have lots of pictures attached.

Comment 7

[Jürgen Ernst]

Unfortunately the above bugs happened to me too. But there are some differences between version 1.5 and 2.0 of Thunderbird and between them installed under windows or linux or run with wine. Maybe this info will help:

We use a linux server with IMAP server installed. To reproduce the bug behaviour I selected a bigger mail with attachment. While it is loading I clicked on another mail in the same folder.

thunderbird   build    operating system   behaviour   
 1.5.0.12      exe     windows XP          A
 2.0.0.7       exe     windows XP          B (CRASH)
 2.0.0.9       exe     windows XP          B (CRASH)

 1.5.0.12    tar.bz2   SuSE linux 9.3      A
 2.0.0.9     tar.bz2   SuSE linux 9.3      A

 2.0.0.9       exe     SuSE linux 9.3      A (run with wine-0.9.50 !!!)

Description of behaviour:
 A) mails in folder vanishes, selected mail is displayed (workaround: user can select another folder and click back to first one --> all mails redisplayed)
 B) CRASH!!! with talkback popup (critical)

As you can see, the critical crash can only be seen with thunderbird 2.0 on a windows machine. The same build (exe-file) can be run in wine on linux. Then there is NO crash!!!

Comment 8

[Magnus Melin [:mkmelin]]

Attachment: proposed fix

The crash (e.g. for TB41444080) leads here: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/netwerk/base/src/nsSocketTransport2.cpp&mark=1676&rev=MOZILLA_1_8_BRANCH#1676

Don't know why it's null, but seems it is at times.

Comment 9

[Magnus Melin [:mkmelin]]

The OpenOutputStream (for symmetry) part of the patch should fix bug 364007.

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 303356 [details] [diff] [review]
proposed fix

this makes no sense. a null *result should have been caught earlier in those functions.

and it _definitely_ shouldn't cause an NS_OK return

Comment 11

[Magnus Melin [:mkmelin]]

Attachment: proposed fix, v2

Bare with me;). Hope this is better.

Comment 12

[Magnus Melin [:mkmelin]]

Comment on attachment 304555 [details] [diff] [review]
proposed fix, v2

Catching it earlier and returning an error.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

But, why did NS_NewPipe2 return a null stream? I don't currently see how it can return success and a null stream. nsPipe::GetInputStream only returns null when there is no mMonitor, and nsPipe::Init makes sure that the monitor is not null.

Comment 14

[Magnus Melin [:mkmelin]]

You're right, I don't see how that could happen either, but if the crash report rows are correct, that's the only place it can happen (what I see at least).

Comment 15

[Wayne Mery (:wsmwk)]

Fernando (and others), can you reproduce with an early release?
  http://www.mozillamessaging.com/en-US/thunderbird/early_releases/

crash-stats (trunk) shows zero crashes with this signature

Comment 16

[Fernando Hartmann]

I tried to reproduce the error in Shredder A3, the crash don't happened but I think it's because when I move back tho the folder with the large email(step that case the crash on TB 2), Shredder don't reload the email again, just show a blank pane like any message was selected tho show. 
With this the switch between the folders don't generate a crash, but the message content (pictures in this case) isn't show anymore. Even I click in other message in my Inbox and then click again in the big message, the message don't is showed again.

Comment 17

[Wayne Mery (:wsmwk)]

you might try http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/3.0b1-candidates/build2/ which will be there a few days yet.

Comment 18

[Fernando Hartmann]

I just tried TB 3.0 b1 in my Windows Vista and I can't reproduce the problem.
Now when a switch between folders all work like a charm.
The problem seems to be solved, I will do more tests and post more informations soon.

Comment 19

[Fernando Hartmann]

I'm back, the problem do not happened to me in my tests.
I thinks it's solved.

Comment 20

[Magnus Melin [:mkmelin]]

I think i'll go ahead and mark this WFM per the comments.

Comment 21

[Wayne Mery (:wsmwk)]

reopening to see if we can resolve this for branch, as this is still a TB2 topcrash. example crash TB51555379...

nsImapProtocol::SetupWithUrl  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 821]
nsImapProtocol::LoadImapUrl  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 1694]
nsImapIncomingServer::GetImapConnectionAndLoadUrl  [mozilla/mailnews/imap/src/nsImapIncomingServer.cpp, line 458]
nsImapMockChannel::ReadFromImapConnection  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 8455]
nsImapMockChannel::OnCacheEntryAvailable  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 8281]
XPTC_InvokeByIndex  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102]
EventHandler  [mozilla/xpcom/proxy/src/nsProxyEvent.cpp, line 561]
0x778b0c24
IsChrome  [mozilla/layout/style/nsRuleNode.cpp, line 1412]
0x03ebe475

TB51793159 calls out line 831 instead of 821


This doesn't happen on trunk, so the question is why? 
Is there a patch on trunk that we can land on branch?

Comment 22

[Wayne Mery (:wsmwk)]

Fernando, others, 
Can you reproduce with ftp://ftp.mozilla.org/pub/thunderbird/releases/3.0a1/ ?

Comment 23

[David :Bienvenu]

Wayne, did you mean to ask about b1 instead of a1?

Comment 24

[Wayne Mery (:wsmwk)]

(In reply to comment #23)
> Wayne, did you mean to ask about b1 instead of a1?

no. I'm hoping to approximate when the problem went away/identify the fix, because this is a topcrash in TB2. I couldn't think of a better starting point than a1

related/same as bug 403272 nsSocketTransport::OpenInputStream?  (which is also a TB2 topcrash. but for trunk appears in 3.0a3 and nowhere else)

Comment 25

[David :Bienvenu]

things are enough different between 3.0 and 2.0 w.r.t. imap and necko and threads that we may not be able to identify a single fix that will help with 2.0

Comment 26

[Wayne Mery (:wsmwk)]

Fernando writes "I just tested the 3.0a1 and the error don't happened. It seems that the problem is solved in 3.0a1 too."

Comment 27

[Wayne Mery (:wsmwk)]

top 5 crash for TB 2.0.0.22

(In reply to comment #25)
> things are enough different between 3.0 and 2.0 w.r.t. imap and necko and
> threads that we may not be able to identify a single fix that will help with
> 2.0

But if we try it on beta channel for TB 2.0.0.23 we can see the results, no?

Comment 28

[David :Bienvenu]

I wouldn't know what fix to try - the one fix in 3.0 that looks related merely fixes a regression that was introduce in 3.0...

Comment 29

[Wayne Mery (:wsmwk)]

is what is still on trunk is a different bug?

bp-106dec60-4bcf-4b64-a2a3-afe852090724 3.0b4pre
nsImapProtocol::SetupWithUrl(nsIURI*, nsISupports*)

0  	thunderbird-bin  	nsImapProtocol::SetupWithUrl  	 mailnews/imap/src/nsImapProtocol.cpp:797
1 	thunderbird-bin 	nsImapProtocol::LoadImapUrl 	mailnews/imap/src/nsImapProtocol.cpp:1972
2 	thunderbird-bin 	nsImapIncomingServer::GetImapConnectionAndLoadUrl 	mailnews/imap/src/nsImapIncomingServer.cpp:422
3 	thunderbird-bin 	nsImapService::GetImapConnectionAndLoadUrl 	mailnews/imap/src/nsImapService.cpp:2210
4 	thunderbird-bin 	nsImapService::FolderCommand 	mailnews/imap/src/nsImapService.cpp:1495
5 	thunderbird-bin 	nsImapService::UpdateFolderStatus 	mailnews/imap/src/nsImapService.cpp:1546
6 	thunderbird-bin 	nsImapMailFolder::UpdateStatus 	mailnews/imap/src/nsImapMailFolder.cpp:1273
7 	thunderbird-bin 	nsImapIncomingServer::GetNewMessagesForNonInboxFolders 	mailnews/imap/src/nsImapIncomingServer.cpp:3057
8 	thunderbird-bin 	nsImapMailFolder::GetNewMessages 	mailnews/imap/src/nsImapMailFolder.cpp:2431
9 	thunderbird-bin 	nsImapIncomingServer::PerformBiff 	mailnews/imap/src/nsImapIncomingServer.cpp:968
10 	libxpcom_core.dylib 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179
11 	thunderbird-bin 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:2454
12 	thunderbird-bin 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1590
13 	libmozjs.dylib 	js_Invoke 	js/src/jsinterp.cpp:1386
14 	libmozjs.dylib 	js_Interpret 	js/src/jsinterp.cpp:5179
15 	libmozjs.dylib 	js_Invoke 	js/src/jsinterp.cpp:1394
16 	libmozjs.dylib 	js_InternalInvoke 	js/src/jsinterp.cpp:1447
17 	libmozjs.dylib 	JS_CallFunctionValue 	js/src/jsapi.cpp:5187
18 	thunderbird-bin 	nsJSContext::CallEventHandler 	dom/src/base/nsJSEnvironment.cpp:2035

Comment 30

[David :Bienvenu]

yes, the code looks pretty different, if the line numbers are right.

Comment 31

[Wayne Mery (:wsmwk)]

bienvenu, it looks like this is headed for closure
- Fernando wrote some months ago it doesn't happen for him in 3.0a1. 
- we might hear from William the reporter (not clear yet)

1. dy think Bug 364007 is the same issue?
2. if the symptoms are gone, are you comfortable with closing this, even if we don't know what fixed it?

I found one v3.1.5 crash but looks like it's a different issue...
bp-fc700140-d281-4ad5-b321-7d4512101026 linux
0	thunderbird-bin	nsImapProtocol::SetupWithUrl	nsImapProtocol.cpp:747
1	thunderbird-bin	nsImapProtocol::LoadImapUrl	nsImapProtocol.cpp:2010
2	thunderbird-bin	nsImapIncomingServer::GetImapConnectionAndLoadUrl	nsImapIncomingServer.cpp:434
3	thunderbird-bin	nsImapService::GetImapConnectionAndLoadUrl	nsImapService.cpp:2189
4	thunderbird-bin	nsImapService::DiddleFlags	nsImapService.cpp:1741
5	thunderbird-bin	nsImapService::AddMessageFlags	nsImapService.cpp:1668
6	thunderbird-bin	nsImapMailFolder::StoreImapFlags	nsImapMailFolder.cpp:3867

Comment 32

[Wayne Mery (:wsmwk)]

reporter writes "I am using 3.1.6 now and can no longer replicate this crash". so 
=> WFM 

v3 crashes FWIW:
(fixed) Bug 582165 - crash [@ nsImapProtocol::SetupWithUrl ] with null m_transport
Bug 507088 - trunk version of crash [@nsImapProtocol::SetupWithUrl(nsIURI*, nsISupports*)]
Bug 558452 - crash [@ nsImapProtocol::SetupWithUrl(nsIURI*, nsISupports*)][@ nsImapProtocol::SetupWithUrl] with null m_runningUrl - aURL isn't nsIImapUrl