Bug 191753 - kmail eats up all memory trying to build a QList
Summary: kmail eats up all memory trying to build a QList
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Unclassified
Component: general (show other bugs)
Version: 1.11.2
Platform: Unlisted Binaries Linux
: NOR crash (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-05 23:40 UTC by Frank Niethardt
Modified: 2009-05-21 14:45 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
fix for kdepim 4.2.3 (2.62 KB, patch)
2009-05-20 11:49 UTC, Frank Niethardt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Niethardt 2009-05-05 23:40:46 UTC
Version:           1.11.2 (using KDE 4.2.2)
Compiler:          gcc (GCC) 4.3.3 
OS:                Linux
Installed from:    Unspecified Linux

I'm using kmail inside of kontact on an archlinux system with kdemod installed:

kdemod-kdepim-kmail 4.2.2-1
kdemod-kdepim-kontact 4.2.2-1
qtmod 4.5.1-1

I have 3 dIMAP accounts and from time to time (not every day, but at least once a week) I experience a moment, where kmail eats up all memory trying to do something. At the end it dies with SIGABRT and the last message in .xsession-errors is, that QList can't allocate memory.

As a side effect the kmailrc file is huge, right now about 6mb. There is one UIDStatusChangedLocally line, that reaches infinity. 

When I try to open kmail again it will start eating memory and die again.

Only solution is to find the line making kmailrc that big and find the place where it repeats and truncate it right there. At the moment it reads:

UIDStatusChangedLocally=19627,19627,19627,...

but normally there is more than just one number there. When I truncate that line and start kontact/kmail again, everything is working fine, till the next time...

After truncating the line, kmailrc is now just 128kb big...
Comment 1 Frank Niethardt 2009-05-12 23:14:41 UTC
At least the last couple of times it was the INBOX foler of my standard eMail Account. Don't know whether it is always happening in this folder...
Comment 2 Frank Niethardt 2009-05-19 19:20:34 UTC
Ok, last couple of times it was every time the INBOX folder of my main dIMAP account. Mainly triggered by walking through the folders and marking threads as read (via a shortcut I set on ctrl-R).

Maybe some spam filtering issue? I use bogofilter...
Comment 3 Frank Niethardt 2009-05-20 11:49:15 UTC
Created attachment 33852 [details]
fix for kdepim 4.2.3

As nobody seems to care I looked over it and changed the 

QList<ulong> mUIDsOfLocallyChangedStatuses

into 

QSet<ulong> mUIDsOfLocallyChangedStatuses;

as it is supposed to be IMHO. Because you have a set of changed UIDs not a (never ending) list of them.

Sadly I can't test the patch myself. Would be great of SOMEONE could look over it...
Comment 4 Thomas McGuire 2009-05-21 14:14:25 UTC
SVN commit 970921 by tmcguire:

Don't grow the list of the UIDs of messages with changed statuses uncontrollable,
which would lead to huge memory consumption and a large kmailrc.

Patch by Frank Thieme <frank at fthieme dot net>, thank you!

BUG: 191753


 M  +5 -5      kmfoldercachedimap.cpp  
 M  +2 -1      kmfoldercachedimap.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=970921
Comment 5 Thomas McGuire 2009-05-21 14:19:58 UTC
SVN commit 970924 by tmcguire:

Backport r970921 by tmcguire from trunk to the 4.2 branch:

Don't grow the list of the UIDs of messages with changed statuses uncontrollable,
which would lead to huge memory consumption and a large kmailrc.

Patch by Frank Thieme <frank at fthieme dot net>, thank you!

CCBUG: 191753



 M  +5 -5      kmfoldercachedimap.cpp  
 M  +2 -1      kmfoldercachedimap.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=970924
Comment 6 Thomas McGuire 2009-05-21 14:45:41 UTC
Frank, thank you for the patch. I've committed it to trunk and the 4.2 branch, so it will be part of KDE 4.2.4 and KDE 4.3 beta2.

Small comment on "nobody seems to care": That is just no true. There is a _vast_ amount of bug reports, and there are not many KMail developers to deal with that. Mostly only me, actually, and I'm doing this in my free time. There is no way I can react to all the bug report, much less fix them.

For the next patch, please use reviewboard, see http://techbase.kde.org/Contribute/Send_Patches#Reviewboard
That way, the patch can't go unnoticed and reviewboard provides some nice features on top of that.