164798 - Regression crashes in IMAP msg handling [@ nsImapProtocol::HandleMessageDownLoadLine]

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[greer]

This crash started showing up in the the 20020823 builds 
   2 (2002082608) Linux 2.4.18-4GB
   1 (2002082508) Windows NT  5.1 build 2600
   1 (2002082404) Linux 2.2.12-20
   2 (2002082308) Windows NT  5.0 build 2195

Based on the timing and the part of the code I figure this is a regression from
one of bienvenu's checkins. -> bienvenu for first look.

Stack Trace:
nsImapProtocol::HandleMessageDownLoadLine()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapProtocol.cpp
line 3176]
nsImapServerResponseParser::msg_fetch_literal()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp
line 2567]
nsImapServerResponseParser::msg_fetch_content()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp
line 1964]
nsImapServerResponseParser::msg_fetch_headers()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp
line 1938]
nsImapServerResponseParser::msg_fetch()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp
line 1083]
nsImapServerResponseParser::numeric_mailbox_data()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp
line 981]
nsImapServerResponseParser::response_data()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp
line 700]
nsImapServerResponseParser::ParseIMAPServerResponse()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp
line 226]
nsImapProtocol::ParseIMAPandCheckForNewMail()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapProtocol.cpp
line 1409]
nsImapProtocol::FetchMessage()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapProtocol.cpp
line 2908]
nsImapProtocol::FolderMsgDumpLoop()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapProtocol.cpp
line 3546]
nsImapProtocol::FolderMsgDump()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapProtocol.cpp
line 3449]
nsImapProtocol::FolderHeaderDump()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapProtocol.cpp
line 3428]
nsImapProtocol::ProcessMailboxUpdate()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapProtocol.cpp
line 3397]
nsImapProtocol::ProcessSelectedStateURL()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapProtocol.cpp
line 2374]
nsImapProtocol::ProcessCurrentURL()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapProtocol.cpp
line 1305]
nsImapProtocol::ImapThreadMainLoop()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapProtocol.cpp
line 1137]
nsImapProtocol::Run()
[/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapProtocol.cpp
line 649]
nsThread::Main()
[/builds/client/linux22/seamonkey/mozilla/xpcom/threads/nsThread.cpp line 583]
_pt_root()
[/builds/client/linux22/seamonkey/mozilla/nsprpub/pr/src/pthreads/ptthread.c
line 217]
libpthread.so.0 + 0x6e67 (0x4020de67)

Source File :
/builds/client/linux22/seamonkey/mozilla/mailnews/imap/src/nsImapProtocol.cpp
line : 3176

Comment 1

[greer]

kw -> crash

Comment 2

[David :Bienvenu]

Yes, must be. I haven't seen this myself, unfortunately, so I'm not sure how to
recreate this.

Comment 3

[David :Bienvenu]

checked in potential fix, though since I can't reproduce this, I can't be sure.

Comment 4

[Olav Vitters]

*** Bug 166196 has been marked as a duplicate of this bug. ***

Comment 5

[[e-mail] (gone - use [e-mail] instead)]

According to Talkback queries, this hasn't crashed since 2002-09-10-14.  That's
really weird, because a fix was checked in before the last crash...
http://bugzilla.mozilla.org/show_bug.cgi?id=166196#c8.  Who knows, maybe this is
some kind of strange race condition that has been fixed elsewhere.

I don't see it in Talkback lately, though.  So I'm verifying it ;-)

Comment 6

[David :Bienvenu]

my guess is that this is mostly fixed, but there's some condition that still
exposes it - I wonder if it's an uninitialized variable or something, which
could explain why that build on the 10th had so many crashes but others don't.
The other possibility is that a single user had the crash multiple times on the
10th, and that there's something special about their folders.

Comment 7

[[e-mail] (gone - use [e-mail] instead)]

Yeah, but running Purify, I haven't seen any UMRs in any IMAP functions/methods,
lately.  I'll keep on eye out for them.