Bug 191753

Summary: kmail eats up all memory trying to build a QList
Product: [Unmaintained] kmail Reporter: Frank Niethardt <frank>
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED FIXED    
Severity: crash    
Priority: NOR    
Version: 1.11.2   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: fix for kdepim 4.2.3

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.