crash [@ nsMsgDBFolder::CallFilterPlugins(nsIMsgWindow*, int*)]

RESOLVED FIXED in Thunderbird 22.0

Status

MailNews Core
Filters
--
critical
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: wsmwk, Assigned: rkent)

Tracking

({crash})

Trunk
Thunderbird 22.0
x86
All
crash
Dependency tree / graph

Thunderbird Tracking Flags

(thunderbird21+ fixed, thunderbird-esr1721+ fixed)

Details

(Whiteboard: [followup to bug 629497], crash signature)

Attachments

(1 attachment)

+++ This bug was initially created as a clone of Bug #541879 +++ which referenced http://getsatisfaction.com/mozilla_messaging/tags/bug_541879


There are still examples of this signature after fixing of Bug #541879 and Bug 629497 (although small spot check does not reveal any with nsPop3Sink::EndMailDelivery on stack).

many have Japanese comments, like bp-960fe760-405f-4bda-8697-c6eef2110830
bp-6156d6ed-8b91-4898-b29e-1baf02110905 version 6 with email address.
0	xul.dll	nsMsgDBFolder::CallFilterPlugins	mailnews/base/util/nsMsgDBFolder.cpp:2586
1	xul.dll	nsMsgLocalMailFolder::UpdateFolder	mailnews/local/src/nsLocalMailFolder.cpp:644 

v7 example bp-b1cb808a-70c5-496a-9a58-791972110920, whose stack is slightly different?
EXCEPTION_ACCESS_VIOLATION_READ
0x0
0	xul.dll	nsMsgDBFolder::CallFilterPlugins	mailnews/base/util/nsMsgDBFolder.cpp:2632
1	xul.dll	nsMsgLocalMailFolder::UpdateFolder	mailnews/local/src/nsLocalMailFolder.cpp:655
2	xul.dll	NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
rkent/bienvenu, is a testcase needed for this?

Mac and linux signature nsMsgDBFolder::CallFilterPlugins

(note: after fix of Bug 629497 in version 6, nsMsgDBFolder::CallFilterPlugins is no longer a topcrash for current versions)
Crash Signature: [@ nsMsgDBFolder::CallFilterPlugins(nsIMsgWindow*, int*)] → [@ nsMsgDBFolder::CallFilterPlugins(nsIMsgWindow*, int*)] [@ nsMsgDBFolder::CallFilterPlugins]

Comment 2

6 years ago
Notice the comments in the v7 log, like this: "I find that 99% of the time when I first open Thunderbird for the day, it crashes. Then when I re-open it, it works fine. Any reason for this?"
Keywords: crashreportid
definitely worthy of someone fixing - it's ranked #11 crash for v3.1.15. And top 75 for version 7 (#7 ranking if you ignore non-mail crashes)


(In reply to aceman from comment #2)
> Notice the comments in the v7 log, like this: "I find that 99% of the time
> when I first open Thunderbird for the day, it crashes. Then when I re-open
> it, it works fine. Any reason for this?"

there are no version 7 comments.  that's a comment from a 3.1.15 crash bp-03db450e-a1f8-4cd8-8f50-b7d792111017
Keywords: crashreportid
Whiteboard: [topcrash v3.1.15]

Comment 4

6 years ago
I landed bug 629497 fix for 3.1.16, so I suspect that number will go down.

Are you saying 67 of our top 75 crashes are in non-mail code? yikes.

I suspect I can ameliorate this issue some by moving the code that checks for the open database to right before it's used. But I wish I knew who was setting mDatabase to null.
(In reply to David :Bienvenu from comment #4)
> I landed bug 629497 fix for 3.1.16, so I suspect that number will go down.

ah, quite right


> Are you saying 67 of our top 75 crashes are in non-mail code? 

pretty close, yeah. which is why I am always so keen on getting attention on our topcrashes caused by core code. roughly 85% of our 300 topcrash signatures indicate core code ...

only 10 "pop3" and "imap" sigs 
nsImapMailFolder::CopyMessagesOffline(nsIMsgFolder*  nsIArray*  int  nsIMsgWindow*  nsIMsgCopyServiceListener*)
nsImapMailFolder::SetUrlState(nsIImapProtocol*  nsIMsgMailNewsUrl*  int  int  unsigned int)
nsImapProtocol::~nsImapProtocol()
nsImapMailFolder::CopyMessagesOffline
nsImapMailFolder::GetDBFolderInfoAndDB(nsIDBFolderInfo**  nsIMsgDatabase**)
nsImapProtocol::SetupWithUrl(nsIURI*  nsISupports*)
nsImapMailFolder::AddMoveResultPseudoKey(unsigned int)
nsPop3Sink::CheckPartialMessages(nsIPop3Protocol*)

only 27 crashes containing the strings "msg" and "folder"

plus a few other oddballs, like ldap


> I suspect I can ameliorate this issue some by moving the code that checks
> for the open database to right before it's used. But I wish I knew who was
> setting mDatabase to null.

if its a protocol log you need - that seems unlikely unless more people start submitting crashes with email addresses so we can get protocol log, or are encouraged to personally file bug reports. (and most are Indian givers anyway, <25% ever respond to a request from us for more info)
Whiteboard: [topcrash v3.1.15] → [post bug 629497]

Updated

6 years ago
Blocks: 694196
no more testcases.

but another variation
nsImapMailFolder::HeaderFetchCompleted as frame 2
bp-c7cb55e9-cddd-4e8f-952c-0b58f2111219
0		@0x0	
1	xul.dll	nsMsgDBFolder::CallFilterPlugins	mailnews/base/util/nsMsgDBFolder.cpp:2604
2	xul.dll	nsImapMailFolder::HeaderFetchCompleted	mailnews/imap/src/nsImapMailFolder.cpp:5846
3	xul.dll	NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
4	xul.dll	nsProxyObjectCallInfo::Run	xpcom/proxy/src/nsProxyEvent.cpp:182
5	xul.dll	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:631
6	xul.dll	NS_ProcessNextEvent_P	objdir-tb/mozilla/xpcom/build/nsThreadUtils.cpp:245
7	xul.dll	mozilla::ipc::MessagePump::Run	ipc/glue/MessagePump.cpp:134
8	xul.dll	MessageLoop::RunInternal	ipc/chromium/src/base/message_loop.cc:221 


and contrary to comment 0, nsPop3Sink::EndMailDelivery is on the stack of 
bp-6c3c7a66-2eb8-400f-acc5-627fb2111223
0	xul.dll	nsMsgDBFolder::CallFilterPlugins	mailnews/base/util/nsMsgDBFolder.cpp:2676
1	xul.dll	nsPop3Sink::EndMailDelivery	mailnews/local/src/nsPop3Sink.cpp:441
2	xul.dll	nsPop3Protocol::GetMsg	mailnews/local/src/nsPop3Protocol.cpp:2912
3	xul.dll	nsPop3Protocol::ProcessProtocolState	mailnews/local/src/nsPop3Protocol.cpp:3987
4	xul.dll	nsMsgProtocol::OnDataAvailable	mailnews/base/util/nsMsgProtocol.cpp:387
5	xul.dll	nsInputStreamPump::OnStateTransfer	netwerk/base/src/nsInputStreamPump.cpp:510
6	xul.dll	nsInputStreamPump::OnInputStreamReady	netwerk/base/src/nsInputStreamPump.cpp:400
Blocks: 629497
starting in version 10, i.e. post bug 681188, the crash signature is now [@ nsMsgDBFolder::CallFilterPlugins(nsIMsgWindow*, bool*)]
Crash Signature: [@ nsMsgDBFolder::CallFilterPlugins(nsIMsgWindow*, int*)] [@ nsMsgDBFolder::CallFilterPlugins] → [@ nsMsgDBFolder::CallFilterPlugins(nsIMsgWindow*, int*)] [@ nsMsgDBFolder::CallFilterPlugins] [@ nsMsgDBFolder::CallFilterPlugins(nsIMsgWindow*, bool*)]
(Reporter)

Updated

5 years ago
Duplicate of this bug: 720502
rkent, there seem to be at least two code spots involved

1. in whitelist code.  
bp-58035a57-57f8-41fb-9056-6574a2120727 has a reporter email address
hg@0
2677 {
kent@2283
2678 // mark this msg as non-junk, because we whitelisted it.
kent@2283
2679
kent@2283
2680 nsCAutoString msgJunkScore;
kent@2283
2681 msgJunkScore.AppendInt(nsIJunkMailPlugin::IS_HAM_SCORE);
kent@2283
2682 mDatabase->SetStringProperty(msgKey, "junkscore", msgJunkScore.get());
kent@2283
2683 mDatabase->SetStringProperty(msgKey, "junkscoreorigin", "whitelist");

1. bp-38dd3623-38e4-441d-81fc-f3ea22120802 is different
hg@0
2634 // get the list of new messages
hg@0
2635 //
hg@0
2636 PRUint32 numNewKeys;
hg@0
2637 PRUint32 *newKeys;
hg@0
2638 rv = mDatabase->GetNewList(&numNewKeys, &newKeys);

#100 crash for TB14
メイルボックスをマウスで次々とブラウズ中、突然停止した。
bp-962ff4cd-3d23-40f0-a9ef-40a0b2120804

thunderbird stop loading plugins and adress book. Locks up when you try to access plugin options
bp-58035a57-57f8-41fb-9056-6574a2120727

I[f?] there is a corrupt filter as it keeps popping up and telling me, then it should halt the incoming mail and direct me to the corrupt filter instead of endless pop ups that crash the program.
bp-3f3eb50e-8f02-4ab2-ba74-aaffb2120807
Whiteboard: [post bug 629497] → [followup to bug 629497]
in bug 694196, Makoto Kato allso says "mDatabase is null".
(Assignee)

Comment 12

4 years ago
Created attachment 713037 [details] [diff] [review]
Use local database reference

This is now my standard approach to this type of crash.
Assignee: nobody → kent
Status: NEW → ASSIGNED
Attachment #713037 - Flags: review?(mbanner)
Comment on attachment 713037 [details] [diff] [review]
Use local database reference

Yeah, I think given the history of this crash, lets take this. We'll let it soak for a cycle, and then push it out to esr.
Attachment #713037 - Flags: review?(mbanner) → review+
tracking-thunderbird21: --- → +
tracking-thunderbird-esr17: --- → 21+
(Assignee)

Comment 14

4 years ago
Checked in https://hg.mozilla.org/comm-central/rev/1f5700c1bd18
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 22.0
Comment on attachment 713037 [details] [diff] [review]
Use local database reference

[Triage Comment]
Taking into beta so that we can assess it there.
Attachment #713037 - Flags: approval-comm-beta+
https://hg.mozilla.org/releases/comm-beta/rev/1e79544624c3
status-thunderbird21: --- → fixed
Comment on attachment 713037 [details] [diff] [review]
Use local database reference

[Triage Comment]
Ok, I've not heard of any issues due to this, so lets take it forward into esr as well.
Attachment #713037 - Flags: approval-comm-esr17+
https://hg.mozilla.org/releases/comm-esr17/rev/91dfd2763ee0
status-thunderbird-esr17: --- → fixed
You need to log in before you can comment on or make changes to this bug.