Bug 75045 - eats all memory when reading a large number of messages
Summary: eats all memory when reading a large number of messages
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Unmaintained
Component: general (show other bugs)
Version: 1.6
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords: triaged
: 75046 159214 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-12 09:05 UTC by Robert Voinea
Modified: 2009-12-19 00:09 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Voinea 2004-02-12 09:05:05 UTC
Version:           1.6 (using KDE 3.2.0, compiled sources)
Compiler:          gcc version 3.2.2
OS:          Linux (i686) release 2.4.21

In my inbox I had about 1000 messages, most of them with large attachments (4-5Mb)... I Started reading them... and the Kontact/KMail jumped to 300Mb memory usage... eating up all the memory and swap and making my system unusable... so I had to reboot... Same behaviour in the KMail...
The messages were not pgp signed

Porbably this is a memory leak...

I have 256Mb ram and same amount swap... P4/2.4GHz

KDE 3.2.0 /KMail 1.6 from contrib/Slackware 9.0 packages
Comment 1 Ladislav Strojil 2004-02-12 09:14:17 UTC
*** Bug 75046 has been marked as a duplicate of this bug. ***
Comment 2 Ingo Klöcker 2004-02-12 11:19:00 UTC
Sorry, but this is not a crash. Please watch KMail's memory usage while you read the large messages and tell us your findings.
Comment 3 Georg Wittenburg 2004-04-04 21:28:29 UTC
I've been experiencing something similar on KDE 3.2.1 from Debian unstable. VmSize and VmRss (as reported by K System Guard) increase when either accessing a PGP signed message (VmRss += 20, most of the time) and when accessing a mail with a large attachement (VmRss += some larger amount). I haven't been able to to trigger this reproducably however: It doesn't seem to be related to whether a message has already been viewed since Kontact was started or not. Over the time VmRss will grow considerably, I observed a value > 80,000 after having Kontact running for two days. The workaround is to simply restart Kontact every other day.
Comment 4 Tom Albers 2005-01-09 22:48:45 UTC
Is this reproducable with kmail 1.7?
Comment 5 Nicholas Allen 2005-02-07 11:42:46 UTC
I am experiencing this problem on KDE 3.3.2 so this bug is still present in the version of kmail that is included with this version of KDE.
Comment 6 Nicholas Allen 2005-02-07 11:53:57 UTC
When I moved ~/Mail to ~/Mail.old then kmail can start up so it is something to do with the size of the mail folder. My Mail folder was only 130MB which is not really that big so this is quite a serious problem with kmail. I am using kmail version 1.7.2.
Comment 7 Robert Voinea 2005-05-30 13:38:17 UTC
I see this behavior no more in kmail 1.8... I guess it was fixed...
Comment 8 A T Somers 2005-07-09 20:36:07 UTC
Sorry, but I still see this behaviour in 1.8. I have seen this behaviour when saving a whole load of pictures I had emailed to my gmail account from my holliday. It looks like memory usage increases when just viewing the messages with the attached pictures (each message is about 6MB), but the problem is much worse when you actually save the attachments using "Save all attachments" from the context menu in the message structure pane. I have seen the memory usage of contact gone up to over 1 GB, which is when my system starts to protest and becomes unusable. It seems like this problem is NOT fixed.
Comment 9 Robert Voinea 2006-03-07 05:37:11 UTC
It happened again. I use KMail-1.8 on Gentoo / KDE 3.5.1.
I started to sort my mails, and after a few hundreds, it eat up all my memory, making the system unusable, util the kernel killed the process (it was kontact, but running the kmail kpart).
I have to mention that some of my mails are GPG Signed / Encrypted.

My system is an Athlon 1GHz / 512MB RAM.
Comment 10 Bernd Klein 2006-04-24 08:37:29 UTC
For a few days, I seem to have this bug behaviour of Kmail as well. I am using version 1.8.2.
As soon as I am browsing through a certain folder (imap), kmail is freezing my computer. Nothing works anymore. No ssh possible! Just a reboot!
Comment 11 wolfgang pfalzgraf 2006-10-02 21:23:26 UTC
I seem to have the same problem: 
I have KMail 1.3.1 (KDE 3.5.1 Level "a" Suse 10.1)
on an IBM x31 thinkpad. 
And my KMail is very slow:

pressing next messages leads to 
about one minute HD-symbol lightning and 
10% personal cpu load and 15 % system cpu load
KMail VM-Size: 105 000
Mail folder size is 400MB
Comment 12 Thomas McGuire 2007-03-13 20:36:59 UTC
Related to bug #110574, not sure if it is quite the same.
Comment 13 Loïc Gomez 2007-12-14 00:27:25 UTC
I'm having a similar issue (cf. A T Somers's comment #8) when saving all attachments of messages. Kmail memory usage grows about the size of saved attachments and never decrease. 

When saving a lot of attachments, I have to restart kmail...
It's been like this ever since I started using kmail, which means for about 3 years. Actually using 1.9.7.
Comment 14 Thomas McGuire 2008-03-13 17:43:55 UTC
*** Bug 159214 has been marked as a duplicate of this bug. ***
Comment 15 Jure Repinc 2008-11-09 20:56:32 UTC
I've checked this with KMail from KDE SVN r881890 (to be in KDE 4.2). I currently have 29500 unread email in my test inbox and I clicked on many of those to try to get memory usage high. Unfortunately I don't have so much messages with pictures so I couldn't check with these. During all this time memory consumption was in reasonable limits (135 MiB memory and 50 MiB shared). So if someone could check again with KMail from KDE 4.1 or SVN and who has a lot pictures it would be great.
Comment 16 Björn Ruberg 2009-12-19 00:09:20 UTC
Well, I have inboxes with 6000 mails and don't experience high memory usage anymore - although I'm remembering having had it with earlier version. As no one reports this for one year, I consider this fixed until someone reports the opposite.