Crash in [@ nsMsgFilterList::ApplyFiltersToHdr]
Categories
(MailNews Core :: Filters, defect)
Tracking
(thunderbird_esr6069+ verified, thunderbird68 verified, thunderbird69 verified)
People
(Reporter: wsmwk, Assigned: jorgk-bmo)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file, 2 obsolete files)
(deleted),
patch
|
aceman
:
review+
jorgk-bmo
:
approval-comm-beta+
|
Details | Diff | Splinter Review |
First appears in 68 beta 20190613171710, so presumably a regression
This bug is for crash report bp-2b38939a-f19a-46ce-ae58-e676a0190627.
Top 10 frames of crashing thread:
0 xul.dll nsMsgFilterList::ApplyFiltersToHdr comm/mailnews/base/search/src/nsMsgFilterList.cpp:289
1 xul.dll nsImapMailFolder::NormalEndMsgWriteStream comm/mailnews/imap/src/nsImapMailFolder.cpp:4291
2 xul.dll nsresult `anonymous namespace'::SyncRunnable4<nsIImapMessageSink, unsigned int, bool, nsIImapUrl*, int>::Run comm/mailnews/imap/src/nsSyncRunnableHelpers.cpp:184
3 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1175
4 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
5 xul.dll nsXULWindow::ShowModal xpfe/appshell/nsXULWindow.cpp:385
6 xul.dll nsContentTreeOwner::ShowAsModal xpfe/appshell/nsContentTreeOwner.cpp:450
7 xul.dll nsWindowWatcher::OpenWindowInternal toolkit/components/windowwatcher/nsWindowWatcher.cpp:1246
8 xul.dll nsWindowWatcher::OpenWindow toolkit/components/windowwatcher/nsWindowWatcher.cpp:290
9 xul.dll NS_InvokeByIndex
Assignee | ||
Comment 1•5 years ago
|
||
There are a few options in the callee. We could also use an error check or something like this:
https://searchfox.org/comm-central/rev/30fb8479949b5246fda13398de98216dcb3ad346/mailnews/imap/src/nsImapMailFolder.cpp#3168
https://searchfox.org/comm-central/rev/30fb8479949b5246fda13398de98216dcb3ad346/mailnews/imap/src/nsImapMailFolder.cpp#4212
Look for GetMessageHeader in nsImapMailFolder.cpp to see all the variations.
Filter man, what do you say?
Assignee | ||
Comment 3•5 years ago
|
||
Oops. Like this we skip running the filter since no one checks the return value. Or do you have a different suggestion?
Check the status of GetMessageHeader?
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
Crashing code added in bug 697522.
Assignee | ||
Comment 5•5 years ago
|
||
Discussed with Aceman on IRC. On a null header the function does nothing since filter->MatchHdr(msgHdr,
returns an error on a null header.
We should also intialise the match result since the matching might have failed and then the result may be undefined and the logging will log garbage.
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/604b7c9f720c
Check that we got a non-null header before running a filter on it (and crashing). r=aceman
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 8•5 years ago
|
||
I think it's proper operation. IMAP messages can disappear for various reasons, so if there gone by the time we come to filter them, there's nothing to do. As you can see, the crash rate is low, so this is not common operation.
Assignee | ||
Comment 9•5 years ago
|
||
TB 68 beta 5:
https://hg.mozilla.org/releases/comm-beta/rev/f53a5e4487e6a27251cd7d45937edef39d05129e
Assignee | ||
Comment 10•5 years ago
|
||
TB 60.9 ESR:
https://hg.mozilla.org/releases/comm-esr60/rev/961f170f6cd0b318650f27ac78f5df948872b35e
Reporter | ||
Comment 11•5 years ago
|
||
V.fixed every place the patch has landed. Thanks.
Description
•