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

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Wayne Mery (:wsmwk)]

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

Comment 1

[Ian Neal]

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

Comment 2

[Ian Neal]

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.

Comment 3

[David :Bienvenu]

Attachment: possible fix

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.

Comment 4

[David :Bienvenu]

I'll plus for now - I'd

Comment 5

[David :Bienvenu]

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...

Comment 6

[David :Bienvenu]

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.

Comment 7

[Wayne Mery (:wsmwk)]

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 :)

Comment 8

[David :Bienvenu]

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.

Comment 9

[David :Bienvenu]

optimistically marking fixed - I've added this bug to the tracking bug of fixes we want for the beta 1 release branch.

Comment 10

[Wayne Mery (:wsmwk)]

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