255581 - consistent crasher -TB07x [@ nsImapProtocol::HandleMessageDownLoadLine] [@ nsImapServerResponseParser::msg_fetch_literal]

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[(not reading, please use [e-mail] instead)]

One of my co-workers is unable to use Thunderbird on Mac.  

He consistently crashes when trying to load his inbox.

Here's the server info:

* OK banzai.net running Eudora Internet Mail Server 3.1

He's running tbird 0.7.3 on Mac OS X version 10.3.5 (Build 7M34)

Here's the stack:

Thread 4 Crashed:
0   org.mozilla.thunderbird      0x00327c10 
nsImapProtocol::HandleMessageDownLoadLine(char const*, int) + 0x2c8
1   org.mozilla.thunderbird      0x0076f228 
nsImapServerResponseParser::msg_fetch_literal(int, int) + 0x29c
2   org.mozilla.thunderbird      0x0076d910 
nsImapServerResponseParser::msg_fetch_content(int, int, char const*) +  0xd4
3   org.mozilla.thunderbird      0x0076b76c 
nsImapServerResponseParser::msg_fetch() + 0x70c
4   org.mozilla.thunderbird      0x0076a768 
nsImapServerResponseParser::response_data(int) + 0x8a0
5   org.mozilla.thunderbird      0x00769568 
nsImapServerResponseParser::ParseIMAPServerResponse(char const*, int) +  0x23c
6   org.mozilla.thunderbird      0x00327280  nsImapProtocol::FetchMessage(char
const*, nsIMAPeFetchFields, int,  unsigned, unsigned, char*) + 0x65c
7   org.mozilla.thunderbird      0x00328ab8 
nsImapProtocol::FolderMsgDumpLoop(unsigned*, unsigned,  nsIMAPeFetchFields) + 0xa0
8   org.mozilla.thunderbird      0x00328750 
nsImapProtocol::FolderMsgDump(unsigned*, unsigned, nsIMAPeFetchFields)  + 0x68
9   org.mozilla.thunderbird      0x00328590 
nsImapProtocol::ProcessMailboxUpdate(int) + 0x4b4
10  org.mozilla.thunderbird      0x00325e3c 
nsImapProtocol::ProcessSelectedStateURL() + 0x1970
11  org.mozilla.thunderbird      0x003236c0  nsImapProtocol::ProcessCurrentURL()
+ 0x3cc
12  org.mozilla.thunderbird      0x00322ff4 
nsImapProtocol::ImapThreadMainLoop() + 0x128
13  org.mozilla.thunderbird      0x00322658 nsImapProtocol::Run() + 0x54
14  libxpcom.dylib               0x07043d5c nsThread::Main(void*) + 0x38
15  libnspr4.dylib               0x0301d46c PR_Select + 0x33c
16  libSystem.B.dylib            0x900246e8 _pthread_body + 0x28

I see nsImapProtocol::HandleMessageDownLoadLine() in talkback quite a bit, see
the url for this bug.

Comment 1

[(not reading, please use [e-mail] instead)]

my co-worker tells me mozilla mail crashes as well as tbird.

Comment 2

[Jay Patel [:jay]]

This looks like a topcrasher with Thunderbird 0.7.3 (and I see crashes in
previous  TB07x releases as well). 

Thunderbird 0.7.2 crashes:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsImapProtocol%3A%3AHandleMessageDownLoadLine&vendor=All&product=All&platform=All&buildid=20040707&sdate=&stime=&edate=&etime=

Thunderbird 0.7.3 crashes:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsImapProtocol%3A%3AHandleMessageDownLoadLine&vendor=All&product=All&platform=All&buildid=20040803&sdate=&stime=&edate=&etime=

It's happening on all platforms and almost all the comments mention deleting
mail.  I wonder if this crash is a result of the problem discussed in bug 249128.  

Here's a snapshot of the latest Talkback data for TB073:
Count   Offset    Real Signature
[ 36   nsImapProtocol::HandleMessageDownLoadLine 999652e8 -
nsImapProtocol::HandleMessageDownLoadLine ]
 
     Crash date range: 09-AUG-04 to 17-AUG-04
     Min/Max Seconds since last crash: 295 - 625103
     Min/Max Runtime: 938 - 625103
 
     Count   Platform List 
     26   Windows XP [Windows NT 5.1 build 2600] 
     10   Windows 2K [Windows NT 5.0 build 2195] 
 
     Count   Build Id List 
     36   2004080301
 
     No of Unique Users        21
 
 Stack trace(Frame) 

	 nsImapProtocol::HandleMessageDownLoadLine
[e:/builds/tbird-0.7.3/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapProtocol.cpp
 line 3262] 
	 nsImapServerResponseParser::msg_fetch_literal
[e:/builds/tbird-0.7.3/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp
 line 2723] 
	 nsImapServerResponseParser::msg_fetch_content
[e:/builds/tbird-0.7.3/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp
 line 2065] 
	 nsImapServerResponseParser::msg_fetch_headers
[e:/builds/tbird-0.7.3/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp
 line 2035] 
	 nsImapServerResponseParser::ParseIMAPServerResponse
[e:/builds/tbird-0.7.3/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp
 line 245] 
	 nsImapProtocol::FetchMessage
[e:/builds/tbird-0.7.3/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapProtocol.cpp
 line 2983] 
	 nsImapProtocol::FolderMsgDumpLoop
[e:/builds/tbird-0.7.3/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapProtocol.cpp
 line 3654] 
	 nsImapProtocol::FolderMsgDump
[e:/builds/tbird-0.7.3/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapProtocol.cpp
 line 3555] 
	 nsImapProtocol::ProcessSelectedStateURL
[e:/builds/tbird-0.7.3/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapProtocol.cpp
 line 1968] 
	 nsImapProtocol::ProcessCurrentURL
[e:/builds/tbird-0.7.3/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapProtocol.cpp
 line 1378] 
	 nsImapProtocol::ImapThreadMainLoop
[e:/builds/tbird-0.7.3/WINNT_5.0_Clobber/mozilla/mailnews/imap/src/nsImapProtocol.cpp
 line 1166]  
 
     (581002)	Comments: While deleting spam
     (576550)	Comments: I was deleteing a lage amount of mail messages
     (576434)	Comments: deleting emails and moving emails from trashcan to local
folder
     (567438)	Comments: Again  Thunderbird was just in the background  being
idle more or less  maybe polling for new mails from the IMAP server.
     (562142)	Comments: Just reading a simple archived email I had opened a few
times already without problems. A plain text email.
     (559288)	Comments: Thunderbird crashed on its own while I was away making
tee. Was standing on a normal text mail in a small sub-box of my inbox when it
crashed.
     (553935)	Comments: Thunderbird was in background
     (551964)	Comments: Clearing the trash folder
     (550750)	Comments: While writing an email
     (550669)	Comments: While deleting spam mails through Shift-Del
     (541011)	Comments: Sending email (had just pressed the Send button).
     (537002)	Comments: requesting new message from server
 
====================================================================================================
     Count   Offset    Real Signature
[ 1   nsImapProtocol::HandleMessageDownLoadLine() e31f41e0 -
nsImapProtocol::HandleMessageDownLoadLine() ]
[ 1   nsImapProtocol::HandleMessageDownLoadLine() d983fef7 -
nsImapProtocol::HandleMessageDownLoadLine() ]
[ 1   nsImapProtocol::HandleMessageDownLoadLine() 32218ea3 -
nsImapProtocol::HandleMessageDownLoadLine() ]
 
     Crash date range: 10-AUG-04 to 11-AUG-04
     Min/Max Seconds since last crash: 1 - 9
     Min/Max Runtime: 7 - 9
 
     Count   Platform List 
     2   [Linux 2.4.20-31.9]      
     1   [Linux 2.6.5-7.104-default]      
 
     Count   Build Id List 
     3   2004080311
 
     No of Unique Users         3
 
 Stack trace(Frame) 

	 nsImapProtocol::HandleMessageDownLoadLine()  
	 nsImapServerResponseParser::msg_fetch_literal()  
	 nsImapServerResponseParser::msg_fetch_content()  
	 nsImapServerResponseParser::msg_fetch_headers()  
	 nsImapServerResponseParser::msg_fetch()  
	 nsImapServerResponseParser::numeric_mailbox_data()  
	 nsImapServerResponseParser::response_data()  
	 nsImapServerResponseParser::ParseIMAPServerResponse()  
	 nsImapProtocol::ParseIMAPandCheckForNewMail()  
	 nsImapProtocol::FetchMessage()  
	 nsImapProtocol::FolderMsgDumpLoop()  
	 nsImapProtocol::FolderMsgDump()  
	 nsImapProtocol::FolderHeaderDump()  
	 nsImapProtocol::ProcessMailboxUpdate()  
	 nsImapProtocol::ProcessSelectedStateURL()  
	 nsImapProtocol::ProcessCurrentURL()  
	 nsImapProtocol::ImapThreadMainLoop()  
	 nsImapProtocol::Run()  
	 nsThread::Main()  
	 _pt_root()  
	 libpthread.so.0 + 0x4484 (0x4059a484)   
 
     (541013)	Comments: selecting a new (unread) email.
     (535076)	Comments: I went from an IMAP folder to my inbox and it crashed.

Comment 3

[David :Bienvenu]

I doubt  bug 249128 is directly involved - I do have an imap protocol log from
someone who has this crash, and I'm going to try to work backwards from the log.

Comment 4

[David :Bienvenu]

Attachment: possible fix

this is just a theory, but I think the problem might arise when we get string
literals with naked CR's in them. There was some code in the string literal
parsing code that was leftover from the old io tunnelling code, but I don't
believe that code makes any sense anymore, and I think it was actually causing
problems. I think you could end up passing an empty string to
HandleMessageDownloadLine, which could cause a crash...so I just removed all
that code. I'm going to run with it and make sure it doesn't cause any
problems...

Comment 5

[Scott MacGregor]

Comment on attachment 156562 [details] [diff] [review]
possible fix

Lemme know what time frame you are thinking about for checking into the branch
vs. time you want to spend testing it.

Comment 6

[(not reading, please use [e-mail] instead)]

with pat's help, david and I have figured out a little more...

we crash
http://lxr.mozilla.org/mozilla/source/mailnews/imap/src/nsImapProtocol.cpp#3266,
because m_curHdrInfo is null.

Comment 7

[David :Bienvenu]

Attachment: proposed fix

this fixes the problem - because of the corrupt inbox on the server, we were
getting a bunch of begin message downloads, without ever getting an end message
download, so we exhausted our cache of headers. When we actually got a real
header, we crashed because we had exhausted our header cache.

The fix is to fake a NormalMessageDownload if we get two begin downloads in a
row. This will generate a blank header, usually, which the user can delete. If
we just ignore the empty header in the imap protocol code, the user will get
told about new messages every time they startup, because we haven't created msg
hdrs for them, which is bad. We could try to automatically delete those
headers, but that could be dangerous. We could try to store something in the db
so that we won't try to download those headers every time, but that could be
tricky - this patch would be required for that last approach anyway...

Comment 8

[David :Bienvenu]

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

Re the previous patch, I'll probably keep that in my back pocket for a while...

Comment 9

[(not reading, please use [e-mail] instead)]

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

thanks for fixing this!

r=sspitzer

if this could make aviary 1.0, that would be great.

Comment 10

[Jay Patel [:jay]]

Nominating for aviary1.0PR and plussing for aviary1.0 since this is a topcrasher
and we have a fix ready.

Comment 11

[David :Bienvenu]

fixed on trunk and 1.0 branch

Comment 12

[(not reading, please use [e-mail] instead)]

a note from pat (the bug reporter) after downloading and trying the tbird
nightly from 8-23-03:

"yep, works like a charm and the results are exactly as he described them with
the headerless messages"

Comment 13

[David :Bienvenu]

changing product

Comment 14

[Mike Kaply [:mkaply]]

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

a=mkaply

Comment 15

[Jay Patel [:jay]]

Adding [@ nsImapServerResponseParser::msg_fetch_literal] to summary for tracking
since a lot of similar crashes are being reported under that stack signature as
well.

Comment 16

[Darin Fisher]

 [scriptable, uuid(38f8f784-b092-11d6-ba4b-00108335942a)]
 interface nsIImapHeaderInfo : nsISupports {
-    readonly attribute nsMsgKey  msgUid;
+    attribute nsMsgKey  msgUid;


Shouldn't we bump the UUID for this interface?  I.e., shouldn't we protect
ourselves against crashes resulting from some wacky t-bird extension dipping
into the unfrozen interface pot?  ;-)

Comment 17

[David :Bienvenu]

that's not an interface that any third party would use, believe me. It's only an
interface because we use it with xpcom proxies.