Closed
Bug 688135
Opened 13 years ago
Closed 11 years ago
crash [@ nsMsgDBFolder::CallFilterPlugins(nsIMsgWindow*, int*)]
Categories
(MailNews Core :: Filters, defect)
Tracking
(thunderbird21+ fixed, thunderbird-esr1721+ fixed)
RESOLVED
FIXED
Thunderbird 22.0
People
(Reporter: wsmwk, Assigned: rkent)
References
Details
(Keywords: crash, Whiteboard: [followup to bug 629497])
Crash Data
Attachments
(1 file)
3.83 KB,
patch
|
standard8
:
review+
standard8
:
approval-comm-beta+
standard8
:
approval-comm-esr17+
|
Details | Diff | Splinter Review |
+++ 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
Reporter | ||
Comment 1•13 years ago
|
||
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]
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
Reporter | ||
Comment 3•13 years ago
|
||
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•13 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.
Reporter | ||
Comment 5•13 years ago
|
||
(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]
Reporter | ||
Comment 6•12 years ago
|
||
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
Reporter | ||
Comment 7•12 years ago
|
||
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 | ||
Comment 9•12 years ago
|
||
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
Reporter | ||
Comment 10•12 years ago
|
||
メイルボックスをマウスで次々とブラウズ中、突然停止した。 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]
Reporter | ||
Comment 11•11 years ago
|
||
in bug 694196, Makoto Kato allso says "mDatabase is null".
Assignee | ||
Comment 12•11 years ago
|
||
This is now my standard approach to this type of crash.
Comment 13•11 years ago
|
||
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+
Updated•11 years ago
|
tracking-thunderbird21:
--- → +
tracking-thunderbird-esr17:
--- → 21+
Assignee | ||
Comment 14•11 years ago
|
||
Checked in https://hg.mozilla.org/comm-central/rev/1f5700c1bd18
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 22.0
Comment 15•11 years ago
|
||
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+
Comment 16•11 years ago
|
||
https://hg.mozilla.org/releases/comm-beta/rev/1e79544624c3
status-thunderbird21:
--- → fixed
Comment 17•11 years ago
|
||
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+
Comment 18•11 years ago
|
||
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.
Description
•