Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 472019 - crash [@ nsMsgDBFolder::CallFilterPlugins(nsIMsgWindow*, int*)]
: crash [@ nsMsgDBFolder::CallFilterPlugins(nsIMsgWindow*, int*)]
: crash, fixed-seamonkey2.0.3
Product: MailNews Core
Classification: Components
Component: Filters (show other bugs)
: unspecified
: x86 Windows Vista
: -- critical (vote)
: Thunderbird 3.1a1
Assigned To: Kent James (:rkent)
Depends on:
  Show dependency treegraph
Reported: 2009-01-03 22:30 PST by Wayne Mery (:wsmwk, NI for questions)
Modified: 2011-06-09 14:58 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

assume that traitService is failing (3.36 KB, patch)
2009-12-28 15:35 PST, Kent James (:rkent)
mozilla: review+
mozilla: superreview+
standard8: approval‑thunderbird3.0.1+
Details | Diff | Splinter Review

Description Wayne Mery (:wsmwk, NI for questions) 2009-01-03 22:30:55 PST
crash [@ nsMsgDBFolder::CallFilterPlugins] both TB2 and trunk - not a topcrash.

Mac - Pressed "dismiss all" on Lightening (16 events to dismiss, using caldev server)
nsMsgDBFolder::CallFilterPlugins	nsMsgDBFolder.cpp:2033
nsImapMailFolder::HeaderFetchCompleted	nsImapMailFolder.cpp:5154
NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179
nsProxyObjectCallInfo::Run	xpcom/proxy/src/nsProxyEvent.cpp:181
nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:510
NS_ProcessNextEvent_P	nsThreadUtils.cpp:227
nsXULWindow::ShowModal	xpfe/appshell/src/nsXULWindow.cpp:397
nsWindowWatcher::OpenWindowJSInternal	embedding/components/windowwatcher/src/nsWindowWatcher.cpp:959
nsWindowWatcher::OpenWindow	embedding/components/windowwatcher/src/nsWindowWatcher.cpp:419
nsPromptService::DoDialog	embedding/components/windowwatcher/src/nsPromptService.cpp:786
nsPromptService::ConfirmEx	embedding/components/windowwatcher/src/nsPromptService.cpp:397
NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179
XPCWrappedNative::CallMethod	js/src/xpconnect/src/xpcwrappednative.cpp:2424
XPC_WN_CallMethod	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1477 

W32 - 	reception de mail
nsMsgDBFolder::CallFilterPlugins  [mozilla/mailnews/base/util/nsMsgDBFolder.cpp, line 2038]
nsMsgLocalMailFolder::UpdateFolder  [mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 684]
XPTC_InvokeByIndex  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102]
XPCWrappedNative::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169]
XPC_WN_CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1387]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3966]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1406]
js_InternalInvoke  [mozilla/js/src/jsinterp.c, line 1481]
JS_CallFunctionValue  [mozilla/js/src/jsapi.c, line 4367]
nsJSContext::CallEventHandler  [mozilla/dom/src/base/nsJSEnvironment.cpp, line 1500]
nsJSEventListener::HandleEvent  [mozilla/dom/src/events/nsJSEventListener.cpp, line 195]
Comment 1 Wayne Mery (:wsmwk, NI for questions) 2009-08-17 06:00:38 PDT
calendar issue??

still quite rare. eg.
bp-b4664cd4-2e36-442e-bd23-95eee2090305  Syncing via CalDav with Google with LOTS of changes. I imported a US Holidays ICS calendar via the mozilla site and it set a 10 minute reminder on ALL the events it imported. I was going through them to remove the reminders.
bp-058a311f-e576-4349-81db-2eac52090519  lightning: "dismiss all" on 106 reminders for a caldav calendar

talkback is down, so didn't get to recheck TB2 stats
Comment 2 Wayne Mery (:wsmwk, NI for questions) 2009-08-17 13:28:25 PDT
not in Thunderbird's top 10 crashes
Comment 3 Wayne Mery (:wsmwk, NI for questions) 2009-12-28 13:44:18 PST
#37 crasher and rising for Thunderbird v3.0.0.

80% of crashes with comments mention lightning/calendar.
however, not all crashes have calendar extension, eg

bp-a365eb43-afda-41a7-aa2d-425732091228 is called from pop
0	thunderbird.exe	nsMsgDBFolder::CallFilterPlugins	 mailnews/base/util/nsMsgDBFolder.cpp:2450
1	thunderbird.exe	nsPop3Sink::EndMailDelivery	mailnews/local/src/nsPop3Sink.cpp:425
2	thunderbird.exe	nsPop3Protocol::GetMsg	mailnews/local/src/nsPop3Protocol.cpp:2543
3	thunderbird.exe	nsPop3Protocol::ProcessProtocolState	mailnews/local/src/nsPop3Protocol.cpp:3633
4	thunderbird.exe	nsMsgProtocol::OnDataAvailable	mailnews/base/util/nsMsgProtocol.cpp:359
5	thunderbird.exe	nsInputStreamPump::OnStateTransfer	netwerk/base/src/nsInputStreamPump.cpp:508
6	thunderbird.exe	nsInputStreamPump::OnInputStreamReady	netwerk/base/src/nsInputStreamPump.cpp:398
7	xpcom_core.dll	nsOutputStreamReadyEvent::Run	xpcom/io/nsStreamUtils.cpp:111
8	xpcom_core.dll	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:521
9	xpcom_core.dll	NS_ProcessNextEvent_P	objdir-tb/mozilla/xpcom/build/nsThreadUtils.cpp:236 

but some are long loopers
bp-16cc832d-9c35-4c73-bf35-0bc3d2091218 (shutdown hang?)
Comment 4 Kent James (:rkent) 2009-12-28 14:00:03 PST
This crash is on the last line of the following code:

2436 PRUint32 count, *proIndices, *antiIndices;
2437 rv = traitService->GetEnabledIndices(&count, &proIndices, &antiIndices);
2438 PRBool filterForOther = PR_FALSE;
2439 for (PRUint32 i = 0; i < count; ++i)
2440 {
2441 // The trait service determines which traits are globally enabled or
2442 // disabled. If a trait is enabled, it can still be made inactive
2443 // on a particular folder using an inherited property. To do that,
2444 // set "dobayes." + trait proID as an inherited folder property with
2445 // the string value "false"
2446 //
2447 // If any non-junk traits are active on the folder, then the bayes
2448 // processing will calculate probabilities for all enabled traits.
2450 if (proIndices[i] != nsIJunkMailPlugin::JUNK_TRAIT)

I am guessing that the traitService is failing, and leaving count as a random value, which then crashes the array. So the suggested fix would be to both check for errors, and initialize count to zero.
Comment 5 Kent James (:rkent) 2009-12-28 15:35:36 PST
Created attachment 419358 [details] [diff] [review]
assume that traitService is failing
Comment 6 David :Bienvenu 2009-12-30 09:55:27 PST
Comment on attachment 419358 [details] [diff] [review]
assume that traitService is failing

It's unclear to me how the trait service could be failing but the rest of your analysis makes sense.
Comment 7 Kent James (:rkent) 2009-12-30 13:57:53 PST
Comment on attachment 419358 [details] [diff] [review]
assume that traitService is failing

checked in
Comment 8 Mark Banner (:standard8) 2010-01-05 03:03:47 PST
Not blocking as this isn't in our significant top crasher range. Wanted thought. Will consider approval request later.
Comment 9 Kent James (:rkent) 2010-01-07 09:00:03 PST
Comment on attachment 419358 [details] [diff] [review]
assume that traitService is failing

Checked in for TB 3.0 as
Comment 10 Wayne Mery (:wsmwk, NI for questions) 2010-01-10 15:26:41 PST
Thanks Kent.

can't verify this is gone - we have no testcase, patch only just landed, and crash frequency is insufficient to say it's gone from trunk or 3.0.1pre (crash rate there is not even 1/month).  So verification can't happen until several days after 3.0.1 ships.

removed [needs 3.0 approval]
Comment 11 Wayne Mery (:wsmwk, NI for questions) 2010-01-25 04:34:48 PST
calendar tie in to traitService? 
can anyone from calendar offer insight?

Bug 541879 filed for crashes that remain in 3.0.1. calendar related crashes with this sig seem to be gone in 3.0.1 - no comments mention calendar and none that I checked list the extension.  however, I can't explain why the crash rate for this sig is not significantly reduced, given that 80% of 3.0.0 crashes with comments cite calendar activity happening at the time of crash. And of crashes without comments, a high % have lightning installed (per spot check). 3.0.0 examples:

Note You need to log in before you can comment on or make changes to this bug.