[IMAP] Crash when moving or deleting messages [@ nsImapProtocol::HandleMessageDownLoadLine]

VERIFIED FIXED in mozilla1.9beta3

Status

MailNews Core
Networking: IMAP
--
critical
VERIFIED FIXED
11 years ago
6 years ago

People

(Reporter: Adam Guthrie, Assigned: Magnus Melin)

Tracking

(4 keywords)

Trunk
mozilla1.9beta3
crash, fixed1.8.1.12, topcrash, topcrash+

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
This is the #8 topcrash for Thunderbird 1.5.0.7. Many of the comments say the crash occurred when deleting a message.

The Linux stacks have bogus line numbers, so here's a Windows stack:

Incident ID: 24102405
Stack Signature	nsImapProtocol::HandleMessageDownLoadLine 999652e8
Product ID	Thunderbird15
Build ID	2006090918
Trigger Time	2006-10-03 19:43:50.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	thunderbird.exe + (004c45e2)
URL visited	
User Comments	detaching attachment from message in inbox
Since Last Crash	497855 sec
Total Uptime	497855 sec
Trigger Reason	Access violation
Source File, Line No.	c:/builds/tinderbox/Tb-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 3384
Stack Trace 	
nsImapProtocol::HandleMessageDownLoadLine  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 3384]
nsImapServerResponseParser::msg_fetch_literal  [mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp, line 2739]
nsImapServerResponseParser::msg_fetch_content  [mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp, line 2059]
nsImapServerResponseParser::msg_fetch_headers  [mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp, line 2029]
nsImapServerResponseParser::ParseIMAPServerResponse  [mozilla/mailnews/imap/src/nsImapServerResponseParser.cpp, line 246]
nsImapProtocol::FetchMessage  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 3053]
nsImapProtocol::FolderMsgDumpLoop  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 3771]
nsImapProtocol::FolderMsgDump  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 3672]
nsImapProtocol::ProcessSelectedStateURL  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 2037]
nsImapProtocol::ProcessCurrentURL  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 1420]
nsImapProtocol::ImapThreadMainLoop  [mozilla/mailnews/imap/src/nsImapProtocol.cpp, line 1142]
(Reporter)

Updated

11 years ago
Severity: normal → critical

Comment 1

11 years ago
I've seen crashes here on Thunderbird 1.0.x, 1.5.x and 2.0 beta 2.

All on win32, all within a Citrix Metaframe XP session and all for one particular user.

See talkback incident TB28944338M for a recent example
#3 crasher for 1.5.0.9

most mention deleting of some form as mentioned in comment 0.
but some also are "sending email" and typing email.
This is also a top 5 crasher for Thunderbird 2.0 and mainly on Windows. Perhaps this should be marked as topcrasher+ because there are at least more than 500 crash reports within the last month.

http://talkback-public.mozilla.org/reports/thunderbird/TB20/TB20-topcrashers.html
OS: Linux → All
This mostly appears when moving or deleting messages on an IMAP account => adjusting summary.
Summary: TB1507 topcrash [@ nsImapProtocol::HandleMessageDownLoadLine] → [IMAP] Crash when moving or deleting messages [@ nsImapProtocol::HandleMessageDownLoadLine]
I was running for myself into this crash yesterday while repeatedly deleting old mails within my sent folder without moving them to trash. I set sorting by size and started with the largest messages first. The stack is the same like above: TB38982946W
odd ... for v1.5.x builds newer than 1.5.0.10 this is WAY down in the ranking (#66). But TB 2.x is holding steady at #6.  Since there is no "topcrash team", I'm setting topcrash+

FWIW, bug 255581 addressed this top of stack a long time ago
Keywords: qawanted, topcrash+
QA Contact: grylchan → networking.imap
(Assignee)

Comment 7

10 years ago
The crash leads here: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/mailnews/imap/src/nsImapProtocol.cpp&mark=3474&rev=MOZILLA_1_8_BRANCH#3474

is m_curHdrInfo null? It looks like it could be in some error situation.
(Assignee)

Comment 8

10 years ago
Created attachment 295807 [details] [diff] [review]
proposed fix
Assignee: bienvenu → mkmelin+mozilla
Status: NEW → ASSIGNED
Attachment #295807 - Flags: superreview?(bienvenu)
Attachment #295807 - Flags: review?(bienvenu)

Comment 9

10 years ago
Comment on attachment 295807 [details] [diff] [review]
proposed fix

I'd love to know why m_curHdrInfo is null, though.
Attachment #295807 - Flags: superreview?(bienvenu)
Attachment #295807 - Flags: superreview+
Attachment #295807 - Flags: review?(bienvenu)
Attachment #295807 - Flags: review+
(In reply to comment #9)
> (From update of attachment 295807 [details] [diff] [review])
> I'd love to know why m_curHdrInfo is null, though.

should we file a new bug on that? 
indeed, m_curHdrInfo seems to like being null (bug 350179 comment 3).
could this be related?

note: there is one hit on crash-stats bp-f0620026-b1ae-11dc-818d-001a4bd43ed6


(Assignee)

Comment 11

10 years ago
(In reply to comment #9)
> I'd love to know why m_curHdrInfo is null, though.

Currently we have
    if (!m_curHdrInfo)
      BeginMessageDownLoad(....);
    m_curHdrInfo->CacheLine(....);

At least in the sequence BeginMessageDownLoad -> StartNewHdr -> GetFreeHeaderInfo

... GetFreeHeaderInfo() can get get into error situations and cause m_curHdrInfo not to get set up. 

Comment 12

10 years ago
Right, thx, yes, that's the immediate cause, but I meant how do those error conditions arise? I've stared at this code a long time over the past couple years, and pretty much convinced myself that the underlying cause is mismatched calls to begin and end message download, and fixed a few possible causes of that, but I think there must be some remaining cases not handled. I'd love to understand it and bulletproof in a more robust way - maybe this is a case where more eyes will help.
(Assignee)

Comment 13

10 years ago
Yeah, that may be harder to figure out. Besides the out of memory situation of course.

Checking in mailnews/imap/src/nsImapProtocol.cpp;
/cvsroot/mozilla/mailnews/imap/src/nsImapProtocol.cpp,v  <--  nsImapProtocol.cpp
new revision: 1.674; previous revision: 1.673
done

->FIXED (fingers crossed)
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Comment 14

10 years ago
Comment on attachment 295807 [details] [diff] [review]
proposed fix

Asking branch approval for this top crasher.
Attachment #295807 - Flags: approval1.8.1.12?
Hardware: PC → All
Target Milestone: --- → mozilla1.9 M11
Version: 1.8 Branch → Trunk
Comment on attachment 295807 [details] [diff] [review]
proposed fix

approved for 1.8.1.12, a=dveditz for release-drivers
Attachment #295807 - Flags: approval1.8.1.12? → approval1.8.1.12+
(Assignee)

Comment 16

10 years ago
MOZILLA_1_8_BRANCH
Checking in mailnews/imap/src/nsImapProtocol.cpp;
/cvsroot/mozilla/mailnews/imap/src/nsImapProtocol.cpp,v  <--  nsImapProtocol.cpp
new revision: 1.612.2.27; previous revision: 1.612.2.26
done
Keywords: fixed1.8.1.12
Looking at the above, there does not seem to be any specific repro scenario for this. Is there one or should be just monitor reports to see if the crash is no longer reported as a topcrash after the fact?

Comment 18

9 years ago
For what it's worth, one of our users was experiencing this crash several times a day, and since I moved him onto the 20080117 nightly build of Thunderbird, the crash has not reoccurred.
Russel, do you mean trunk or 1.8 branch nightly build? If it's 1.8 branch we could mark this verified.

Also Talkback and Socorro don't report a crash with a build id newer as the check-in for trunk and 1.8 nightly builds.

Comment 20

9 years ago
Hm, not sure. I think trunk - the about box reads

"version 3.0a1pre (2008011703)"

I'll find the 1.8 nightly and give that a try.
This should be verified in ftp://ftp.mozilla.org/pub/thunderbird/nightly/2.0.0.12-candidates/rc1/, not a nightly, since that is the build we are planning on releasing for Thunderbird 2.0.0.12. The nightly may have other changes since it is from after we forked.
Any luck, Russell?
Product: Core → MailNews Core
Lets mark it verified for 1.9. No reports listed within the last months.
Status: RESOLVED → VERIFIED
Keywords: qawanted
Crash Signature: [@ nsImapProtocol::HandleMessageDownLoadLine]
You need to log in before you can comment on or make changes to this bug.