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

RESOLVED WORKSFORME

Status

MailNews Core
Filters
--
critical
RESOLVED WORKSFORME
7 years ago
10 months ago

People

(Reporter: wsmwk, Unassigned)

Tracking

({crash})

Trunk
x86
Windows Vista
crash

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rare], crash signature)

(Reporter)

Description

7 years ago
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

7 years ago
Crash Signature: [@ nsMsgFilter::LogRuleHit(nsIMsgRuleAction*, nsIMsgDBHdr*)]
(Reporter)

Comment 1

6 years ago
<1 crash per month per version 
most recent is bp-07fea0f0-fb32-4440-bcdc-e521b2111218 version 8
Whiteboard: [rare]

Comment 2

6 years ago
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

6 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 4

6 years ago
Can you do it?

Comment 5

5 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)

Updated

4 years ago
See Also: → bug 797710

Comment 6

4 years ago
Wayne, are there any recent occurrences of this?

Updated

2 years ago
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
Last Resolved: 10 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.