[Bug 169048] Crashes when applying all filters on IMAP folder [KMail::ActionScheduler::actionMessage, KMail::ActionScheduler::filterMessage]
Christophe Giboudeaux
cgiboudeaux at gmail.com
Thu Feb 10 10:28:01 GMT 2011
https://bugs.kde.org/show_bug.cgi?id=169048
--- Comment #44 from Christophe Giboudeaux <cgiboudeaux gmail com> 2011-02-10 11:27:55 ---
from bug 169646:
This bug is still happening.
kmail 1.13.2
KDE 4.4.2
linux kernel 2.6.33-gentoo-r1 (x86_64)
Gentoo packages.
Interestingly, my other setup with 32-bit linux on Sabayon Linux doesn't crash
using exact same rule. Not sure why.
Backtrace:
Thread 1 (Thread 0x7f457240c750 (LWP 11155)):
[KCrash Handler]
#5 0x00007f4570dbfb62 in
KMail::ActionScheduler::actionMessage(KMFilterAction::ReturnCode) () from
/usr/lib64/libkmailprivate.so.4
#6 0x00007f4570dbfe1a in KMail::ActionScheduler::filterMessage() () from
/usr/lib64/libkmailprivate.so.4
#7 0x00007f4570dc05ba in
KMail::ActionScheduler::qt_metacall(QMetaObject::Call, int, void**) () from
/usr/lib64/libkmailprivate.so.4
#8 0x00007f456ccb7147 in QMetaObject::activate(QObject*, QMetaObject const*,
int, void**) () from /usr/lib64/qt4/libQtCore.so.4
#9 0x00007f456ccb3bd3 in QObject::event(QEvent*) () from
/usr/lib64/qt4/libQtCore.so.4
Liberal sprinkling of debug statements in the area reveals that the variable
"action" is pointing at 0x21, an invalid but non-zero address which passes the
mFilterAction check in actionMessage(). This causes a segfault when accessed
later.
How does that happen? Here's the current code that checks for the end of the
action list:
498 KMFilterAction *action = mFilterAction;
499 // mFilterAction = (*mFilterIt).actions()->next();
500 if ( ++mFilterActionIt == (*mFilterIt)->actions()->end() )
501 mFilterAction = 0;
502 else mFilterAction = (*mFilterActionIt);
503 action->processAsync( *mMessageIt );
504 }
The problem is we're checking if the *NEXT* action is the end. What about the
*CURRENT* one? Sure it's supposed to be already checked when we advance the
pointer there. Except that the first action isn't assigned by this iterator
advancing code. It's initialized in filterMessage():
mFilterActionIt = (*mFilterIt)->actions()->begin();
mFilterAction = (*mFilterActionIt);
actionMessage();
What's happening here is that begin() == end() since the list is empty. We
didn't verify that mFilterActionIt isn't end (and therefore invalid) before
dereferencing it. Since this is an iterator, not a pointer, we won't crash --
yet. But mFilterAction will get random garbage. If said random garbage happens
to be non-zero, actionMessage() will then try to dereference it as a pointer
and hence the crash.
Suggested patch:
--- kmail/actionscheduler.cpp.orig 2010-04-16 19:03:55.853213672 -0700
+++ kmail/actionscheduler.cpp 2010-04-16 20:07:46.071964041 -0700
@@ -659,7 +659,7 @@ void ActionScheduler::actionMessage(KMFi
mResult = ResultCriticalError;
finish(); //must handle critical errors immediately
}
- if (mFilterAction) {
+ if (mFilterActionIt != (*mFilterIt)->actions()->end()) {
KMMessage *msg = message( *mMessageIt );
if (msg) {
if ( FilterLog::instance()->isLogging() ) {
@@ -668,10 +668,7 @@ void ActionScheduler::actionMessage(KMFi
FilterLog::instance()->add( logText, FilterLog::appliedAction );
}
KMFilterAction *action = mFilterAction;
-// mFilterAction = (*mFilterIt).actions()->next();
- if ( ++mFilterActionIt == (*mFilterIt)->actions()->end() )
- mFilterAction = 0;
- else mFilterAction = (*mFilterActionIt);
+ mFilterAction = *(++mFilterActionIt);
action->processAsync( msg );
}
} else {
Suggested workaround:
As a temporary work around, people like me who need this to set a "stop
processing here" rule with no action and matching sender =
my_boss at my_company.com to make sure important messages doesn't get filtered can
assign a sound as action.
That action will have no effect except being extremely irritating when a whole
bunch of messages matching the rule arrives. This can be avoided by recording a
wav file of silence and using it as the action.
--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the Kdepim-bugs
mailing list