Closed Bug 467114 Opened 11 years ago Closed 11 years ago

crash [@ nsImapMailFolder::NormalEndHeaderParseStream(nsIImapProtocol*, nsIImapUrl*)]

Categories

(MailNews Core :: Networking: IMAP, defect, critical)

x86
Windows Vista
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wsmwk, Assigned: Bienvenu)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(1 file)

from crash-stats this is #4 crasher for 3.0b1pre. doesn't appear in top 500 of talkback

crash [@ nsImapMailFolder::NormalEndHeaderParseStream(nsIImapProtocol*, nsIImapUrl*)]

up to build 2008112700.
back at least as far as 2008100600/aka 3.0a3 (crash stats still won't let me go back more than two weeks - so it could be older).

crash comments
IMAP update.
Crashed.
Crashed without activity.
Crashed on update.
crashed on update or IMAP refresh (not sure which).
Crashed on IMAP update.
Crashed on autoupdate.
crashed during IMAP update.

crash with the most recent build
bp-40affe6b-9b2a-4ce3-837f-2a4962081128
nsImapMailFolder::NormalEndHeaderParseStream	nsImapMailFolder.cpp:2819
nsImapMailFolder::ParseMsgHdrs	nsImapMailFolder.cpp:2733
NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101
nsEventQueue::GetEvent	xpcom/threads/nsEventQueue.cpp:100
nsProxyObjectCallInfo::Run	xpcom/proxy/src/nsProxyEvent.cpp:181
nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:510
NS_ProcessNextEvent_P	nsThreadUtils.cpp:227
nsBaseAppShell::Run	widget/src/xpwidgets/nsBaseAppShell.cpp:170
nsAppStartup::Run	toolkit/components/startup/src/nsAppStartup.cpp:192
XRE_main	toolkit/xre/nsAppRunner.cpp:3264
NS_internal_main	nsMailApp.cpp:103
wmain	toolkit/xre/nsWindowsWMain.cpp:87
__tmainCRTStartup	crtexe.c:594
kernel32.dll@0x27d29
26 crashes on windows in the last week
45 crashes on windows in the last 2 weeks
Crash stats don't seem to be happy going back much further than that.
Happens on SM (BuildID 20081130001326) as well as TB trunks
Flags: blocking-thunderbird3.0b1?
I seem to crash most frequently when I have a compose window open and a new email arrives but not sure that is the only circumstance.
Attached patch possible fixSplinter Review
I really don't know where we're crashing, nor can I reproduce this problem, but if m_newMsgHdr were null, we would crash. It's worth trying this on the trunk and seeing if it helps.
Assignee: nobody → bienvenu
Attachment #350980 - Flags: superreview?(bugzilla)
Attachment #350980 - Flags: review?(bugzilla)
I'll plus for now - I'd
oops, premature commit - I'm not sure if we should plus this or not - it would be great if this patch fixed the problem, but I'd want evidence of that before taking the risk of the patch, and going through respins...
Attachment #350980 - Flags: superreview?(bugzilla)
Attachment #350980 - Flags: superreview+
Attachment #350980 - Flags: review?(bugzilla)
Attachment #350980 - Flags: review+
The other callers of the function I'm changing either check the resulting out pointer for null, or the rv and the out pointer, so they should all be OK with this change.
re: comment 5 I can't be sure this is a legit topcrash.  8 crashes on
11-26 for perhaps 2 people (hard to say) skews the stats - otherwise only avg 2 crashes per day.
http://crash-stats.mozilla.com/report/list?product=Thunderbird&version=Thunderbird%3A3.0b1pre&query_search=signature&query_type=contains&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsImapMailFolder%3A%3ANormalEndHeaderParseStream%28nsIImapProtocol%2A%2C%20nsIImapUrl%2A%29

If we get this on trunk and monitor both trunk and 3.0b1 for the next 2-3 days
I think we will get a clearer sense of whether this is needed for 3.0b1 ... we
already have 4 unique crashes for 3.0b1 :)
ok, possible fix checked in. We need to see if the crash still shows up in the crash stats in builds with this fix.

This wouldn't be a new crash, but the imap auto sync stuff would make us more likely to run into problems, just because we update folders much more than we did before.
Whiteboard: [possible fix landed on trunk]
Blocks: 467813
optimistically marking fixed - I've added this bug to the tracking bug of fixes we want for the beta 1 release branch.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
not marking v.fixed yet. but noting with the fix out ~2days optimistically it seems gone:
- last crash - TB build 20081201031225, SM 20081130001326
- prior to that, TB and SM each had ~2 crashes per day.

and no crashes so far for 3.0b1, which simply indicates to me not enough users to surface the crash.  We'll have to watch trunk and 3.0b1 a few more days before v.fixed
Whiteboard: [possible fix landed on trunk]
Flags: blocking-thunderbird3.0b1?
Product: Core → MailNews Core
Crash Signature: [@ nsImapMailFolder::NormalEndHeaderParseStream(nsIImapProtocol*, nsIImapUrl*)]
You need to log in before you can comment on or make changes to this bug.