| Summary: | Kmail crashes when applying filter with no rules | ||
|---|---|---|---|
| Product: | [Unmaintained] kmail | Reporter: | th |
| Component: | filtering | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | crash | CC: | christophe, clement.cc, jatoivol |
| Priority: | NOR | ||
| Version: | 1.10.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Suggested fix | ||
|
Description
th
2008-08-23 09:52:34 UTC
Please read the following page and provide a useful backtrace for this crash : http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports I can not reproduce this. With a clean configuration / new user, I composed a empty test message with just a subject, saved that as a draft, created a folder named "Test" under the inbox and moved the draft message to there. Then I tried your steps. No crash. Please try to reproduce this with a clean config or a new user and post the steps to reproduce. Also, your backtrace is unfortunately useless, because it misses the debug symbols of KMail. See http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports on how to get a better backtrace. Closing due to lack of feedback. Please reopen if you obtained a better backtrace by following the steps described in http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports . Thank you. 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.
Created attachment 42833 [details]
Suggested fix
Check the interator instead of the pointer derived from the iterator, which could be invalid but non-null.
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@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. *** Bug 265649 has been marked as a duplicate of this bug. *** *** This bug has been marked as a duplicate of bug 169048 *** |