Closed Bug 612066 Opened 14 years ago Closed 8 years ago

crash [@ nsMsgFilter::LogRuleHit(nsIMsgRuleAction*, nsIMsgDBHdr*)]

Categories

(MailNews Core :: Filters, defect)

x86
Windows Vista
defect
Not set
critical

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
Crash Signature: [@ nsMsgFilter::LogRuleHit(nsIMsgRuleAction*, nsIMsgDBHdr*)]
<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.
"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.
Can you do it?
(In reply to :aceman from comment #4) > Can you do it? It's a little too rare to interest me at the moment.
See Also: → 797710
Wayne, are there any recent occurrences of this?
Crash Signature: [@ nsMsgFilter::LogRuleHit(nsIMsgRuleAction*, nsIMsgDBHdr*)] → [@ nsMsgFilter::LogRuleHit(nsIMsgRuleAction*, nsIMsgDBHdr*)] [@ nsMsgFilter::LogRuleHit]
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.