Closed
Bug 612066
Opened 14 years ago
Closed 8 years ago
crash [@ nsMsgFilter::LogRuleHit(nsIMsgRuleAction*, nsIMsgDBHdr*)]
Categories
(MailNews Core :: Filters, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: wsmwk, Unassigned)
References
Details
(Keywords: crash, Whiteboard: [rare])
Crash Data
crash [@ nsMsgFilter::LogRuleHit(nsIMsgRuleAction*, nsIMsgDBHdr*)]
bp-03fe85a0-dada-4521-8cdb-344e52101111
0 thunderbird.exe nsMsgFilter::LogRuleHit mailnews/base/search/src/nsMsgFilter.cpp:494
1 thunderbird.exe nsMsgFilterAfterTheFact::ApplyFilter mailnews/base/search/src/nsMsgFilterService.cpp:506
2 thunderbird.exe nsMsgFilterAfterTheFact::OnSearchDone mailnews/base/search/src/nsMsgFilterService.cpp:439
3 thunderbird.exe nsMsgSearchSession::NotifyListenersDone mailnews/base/search/src/nsMsgSearchSession.cpp:620
4 thunderbird.exe nsMsgSearchSession::TimerCallback mailnews/base/search/src/nsMsgSearchSession.cpp:556
5 xpcom_core.dll nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:427
6 xpcom_core.dll nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:519
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ nsMsgFilter::LogRuleHit(nsIMsgRuleAction*, nsIMsgDBHdr*)]
Reporter | ||
Comment 1•13 years ago
|
||
<1 crash per month per version
most recent is bp-07fea0f0-fb32-4440-bcdc-e521b2111218 version 8
Whiteboard: [rare]
I am not sure why this would crash:
nsresult rv = m_filterList->GetLogStream(getter_AddRefs(logStream));
It seems http://hg.mozilla.org/releases/comm-release/annotate/3512c97aa960/mailnews/base/search/src/nsMsgFilter.cpp#l503 has proper null checks in place.
The reports still continue in TB14, last one is bp-823492eb-b59e-45f7-862c-c01752120827.
Comment 3•12 years ago
|
||
"I am not sure why this would crash"
m_filterList is a simple pointer to a refcounted object. It is not done as a nsCOMPtr because that would potentially introduce a reference count cycle (generally children should not hold references to their parents).
So my theory of this crash is that the filter list object has been destroyed, but that does not affect the m_filterList pointer which would still be non-null, hence the passed check and the crash.
One possible solution to this would be to use a weak pointer for m_filterList. That would stop the crash, but would still result in the filter itself failing in those cases where the filter list has been destroyed. But that is better than a crash of course.
Comment 5•12 years ago
|
||
(In reply to :aceman from comment #4)
> Can you do it?
It's a little too rare to interest me at the moment.
Reporter | ||
Comment 7•10 years ago
|
||
Updated•9 years ago
|
Crash Signature: [@ nsMsgFilter::LogRuleHit(nsIMsgRuleAction*, nsIMsgDBHdr*)] → [@ nsMsgFilter::LogRuleHit(nsIMsgRuleAction*, nsIMsgDBHdr*)]
[@ nsMsgFilter::LogRuleHit]
Comment 8•8 years ago
|
||
I'm marking this bug as WORKSFORME as bug crashlog signature didn't appear from a long time (over half year) [except some obsolete <32 versions, no crashes starting since 32 version].
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•