350179 - crash while loading headers for an IMAP folder [@ nsImapProtocol::NormalMessageEndDownload]

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[t3rmin4t0r]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.3) Gecko/20060523 Ubuntu/dapper Firefox/1.5.0.3
Build Identifier: Mozilla Thunderbird version 1.5.0.2 (20060820)

While loading the Bulk-Mail folder on my mail server, thunderbird dumps core. The coredump is nearly at the end of the header download and seems to originate from the following location.

(gdb) thread 2
[Switching to thread 2 (process 22704)]#0  0x00002aaaab44636e in raise () from /lib/libpthread.so.0
(gdb) bt
#0  0x00002aaaab44636e in raise () from /lib/libpthread.so.0
#1  0x0000000000417d30 in nsProfileLock::FatalSignalHandler (signo=11) at nsProfileLock.cpp:206
#2  <signal handler called>
#3  0x00002aaab3305e04 in nsImapProtocol::NormalMessageEndDownload (this=0x2b58010) at nsImapProtocol.cpp:3390
#4  0x00002aaab3326cd2 in nsImapServerResponseParser::msg_fetch (this=0x2b582a8) at nsImapServerResponseParser.cpp:1216
#5  0x00002aaab33276bc in nsImapServerResponseParser::numeric_mailbox_data (this=0x2b582a8) at nsImapServerResponseParser.cpp:1012
#6  0x00002aaab3324df6 in nsImapServerResponseParser::response_data (this=0x2b582a8, advanceToNextLine=1) at nsImapServerResponseParser.cpp:752
#7  0x00002aaab331f200 in nsImapServerResponseParser::ParseIMAPServerResponse (this=0x2b582a8, 
    currentCommand=0x2cb40a0 "4 UID fetch 54864:54867,54869:54877,54880:54891,54893:56756 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Con"..., aIgnoreBadAndNOResponses=0) at nsImapServerResponseParser.cpp:246
#8  0x00002aaab33004e4 in nsImapProtocol::ParseIMAPandCheckForNewMail (this=0x2b58010, 
    commandString=0x2cb40a0 "4 UID fetch 54864:54867,54869:54877,54880:54891,54893:56756 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Con"..., aIgnoreBadAndNOResponses=0) at nsImapProtocol.cpp:1502
#9  0x00002aaab330ed3f in nsImapProtocol::FetchMessage (this=0x2b58010, messageIds=0xfd9878 "54864:54867,54869:54877,54880:54891,54893:56756", 
    whatToFetch=kHeadersRFC822andUid, idIsUid=1, startByte=0, endByte=0, part=0x0) at nsImapProtocol.cpp:3012
#10 0x00002aaab3313a37 in nsImapProtocol::FolderMsgDumpLoop (this=0x2b58010, msgUids=0x19258a0, msgCount=1354, fields=kHeadersRFC822andUid) at nsImapProtocol.cpp:3729
#11 0x00002aaab3313b0e in nsImapProtocol::FolderMsgDump (this=0x2b58010, msgUids=0x19258a0, msgCount=1354, fields=kHeadersRFC822andUid) at nsImapProtocol.cpp:3630
#12 0x00002aaab3313b46 in nsImapProtocol::FolderHeaderDump (this=0x2b58010, msgUids=0x19258a0, msgCount=1354) at nsImapProtocol.cpp:3610
#13 0x00002aaab331aa63 in nsImapProtocol::ProcessMailboxUpdate (this=0x2b58010, handlePossibleUndo=1) at nsImapProtocol.cpp:3576
#14 0x00002aaab33163a7 in nsImapProtocol::ProcessSelectedStateURL (this=0x2b58010) at nsImapProtocol.cpp:2167
#15 0x00002aaab3319115 in nsImapProtocol::ProcessCurrentURL (this=0x2b58010) at nsImapProtocol.cpp:1378
#16 0x00002aaab3319e8d in nsImapProtocol::ImapThreadMainLoop (this=0x2b58010) at nsImapProtocol.cpp:1140
#17 0x00002aaab331a026 in nsImapProtocol::Run (this=0x2b58010) at nsImapProtocol.cpp:931


Reproducible: Always

Steps to Reproduce:
1. Open thunderbird 
2. Login
3. Open Bulk Mail folder
4. Wait for thunderbird to segv




The thunderbird is built from ubuntu source debs and with "-g", no-strip, with all the patches that ubuntu ships. 

The servers being hit are two of my office servers, tunnelled over ssh. One of them is a dovecot over SSL (9930). The other is a homebrew (in-house) IMAP server which runs over NFS off a NetApp filer with replication. That's the one that's causing the crash here.

In short, the server is not to be trusted and could be sending bad input. But even then, it should give an error gracefully, not SEGV

Comment 1

[David :Bienvenu]

Would it be possible to get an imap protocol log of a session where you crash? You can send it to me, and xxx out sensitive info if you want...Thx!

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Comment 2

[t3rmin4t0r]

Find the imap logs at http://t3.dotgnu.info/code/bulk-mail-crash.log.bbz (bzip2)

I can provide a core file if need be, but it might not be very useful unless you have the binary I built too.

(gdb) p m_curHdrInfo 
$3 = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}

#6  0x00002aaab3324df6 in nsImapServerResponseParser::response_data (this=0x2b582a8, advanceToNextLine=1) at nsImapServerResponseParser.cpp:752
752             numeric_mailbox_data();

(gdb) p this->fCurrentLine
$7 = 0x12f66a0 "* 2382 FETCH (FLAGS () RFC822.SIZE 12194 UID 56748 BODY[HEADER.FIELDS (FROM TO CC SUBJECT DATE MESSAGE-ID PRIORITY X-PRIORITY REFERENCES NEWSGROUPS IN-REPLY-TO CONTENT-TYPE)] {1284}\r\n"

(gdb) p this->fCurrentTokenPlaceHolder
$8 = 0x28b6269 "UID 56748 BODY[HEADER.FIELDS (FROM TO CC SUBJECT DATE MESSAGE-ID PRIORITY X-PRIORITY REFERENCES NEWSGROUPS IN-REPLY-TO CONTENT-TYPE)] {1284}\r\n"

(gdb) p this->fLineOfTokens
$9 = 0x28b6240 "*"

(gdb) p this->fHighestRecordedUID
$10 = 56756

(gdb) p this->fFetchResponseIndex
$11 = 2382

(gdb) p this->fNextToken
$12 = 0x28b6263 "12194"

HTH.

Comment 3

[David :Bienvenu]

thx, we're crashing because m_curHdrInfo is null. I just have to figure out how, between the log and those variable values.

Have you tried a 2.0 Alpha build to see if it has the same problem?

Comment 4

[David :Bienvenu]

1124096352[1e9c110]: 1e92e00:localhost:S-Bulk Mail:CreateNewLineFromSocket: * 2382 FETCH (FLAGS () RFC822.SIZE 12194 UID 56748 BODY[HEADER.FIELDS (FROM TO CC SUBJECT DATE MESSAGE-ID PRIORITY X-PRIORITY REFERENCES NEWSGROUPS IN-REPLY-TO CONTENT-TYPE)] {1284}
1124096352[1e9c110]: 1e92e00:localhost:S-Bulk Mail:STREAM:CLOSE: Normal Message End Download Stream

We should be doing a Begin Message Download Stream instead of End Download Stream, and that's why we're crashing.

Comment 5

[David :Bienvenu]

when you crash, what are fReceivedHeaderOrSizeForUID and fCurrentResponseUID?

Comment 6

[t3rmin4t0r]

(gdb) p this->fReceivedHeaderOrSizeForUID
$2 = 4294967295

(gdb) p this->fCurrentResponseUID
$3 = 4294967295


(gdb) p this->fUidOfSingleMessageFetch
$5 = 45483160

(gdb) p this->fFetchResponseIndex
$6 = 2382

(gdb) p this->fStatusNextUID
$7 = 4294967295

For what it's worth, not that most of it made sense to me.

Comment 7

[t3rmin4t0r]

Attachment: gdb logs

break nsIMAPGenericParser::AdvanceToNextToken
commands 
  p this->fCurrentLine
  p this->fCurrentTokenPlaceHolder
  p this->fNextToken
  bt 5 
  thread
  c
end

Comment 8

[David :Bienvenu]

fCurrentResponseUID and fReceivedHeaderOrSizeForUID are both -1 - I'll look at the code and see if I can figure out how that could happen, and what to do about it.

Comment 9

[David :Bienvenu]

From that log, the server is missing at least three indices in the fetch flags 1:* response - the indices are supposed to be monotonically increasing but three are skipped: 2197, 2149, and 2151.  I believe that will throw off our nsImapFlagAndUidState object, and throw off the downstream uid's, such that GetUidOfMessage will return -1, which prevents us from creating m_curHdrInfo. Fixing the crash is probably pretty easy, but handling the missing indexes correctly might be more challenging.

Comment 10

[David :Bienvenu]

Attachment: proposed fix

This change makes us somewhat tolerant of gaps in the message indexes - the missing entries will be set to uid 0, and the downstream indices will actually be found (it was the failure to find the uid of message indexes after the gap that was causing the crash).

UID 0 is illegal, so I had to make FindKeysToAdd/Delete ignore 0 UID's. 

I changed nsIImapFlagAndUidState.idl, but that's a private interface.

The core change was to use the message index as returned by the server to index the flag state - that simplifies the code quite a bit. I'm not sure why we didn't do that - it certainly seems like the right thing to do.

Comment 11

[David :Bienvenu]

should be fixed on trunk.

Comment 12

[David :Bienvenu]

fix checked into 1.8.1 branch

Comment 13

[t3rmin4t0r]

(In reply to comment #9)
> the server is missing at least three indices in the fetch flags 1:* response 

Thanks for the analysis & fix, I will let the server devs know about this. 

Comment 14

[Udo Richter]

This probably caused a regression, see bug 358635

Comment 15

[Marcia Knous [:marcia]]

Reporter - can you assist in verifying this fix by trying out the Tbird release candidate in this directory: ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2.0.0.0-candidates. Thanks.