Bug 88427 - Memory leak when retrieving messages
Summary: Memory leak when retrieving messages
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: kmail
Classification: Applications
Component: general (show other bugs)
Version: 1.7.1
Platform: Slackware Linux
: NOR normal with 20 votes (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 208307 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-08-30 10:02 UTC by kek had
Modified: 2013-07-01 17:29 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Mail which causes very fast eating memory by kmail (114.60 KB, application/octet-stream)
2004-10-27 00:28 UTC, Arkadiusz Miskiewicz
Details
Kmail line in ksysguard (3.72 KB, image/png)
2004-12-16 23:28 UTC, Boyan Ivanov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kek had 2004-08-30 10:02:52 UTC
Version:           1.7 (using KDE 3.3.0, SuSE)
Compiler:          gcc version 3.3.1 (SuSE Linux)
OS:                Linux (i686) release 2.6.8.1

I had my Kontact running through the weekend. After coming back to work, my workstation was very very slow. After doing a top, I saw that Kontact was using 85% of the memory and also the swap (1 GB) was full. After killing Kontact everything went back to normal. The active application in Kontact was Kmail at the time.

This is of course a memory leak in the application.
Comment 1 Carsten Burghardt 2004-08-30 10:40:49 UTC
This is pretty hard to debug with this explanation. You could check from time to time if kmail is allocating more memory after certain actions (e.g. moving mails).
Comment 2 kek had 2004-08-30 16:49:39 UTC
I know this is not a good dexcription, but the situation made it difficult 
for me to find more info. Of what I can tell is that when I left the system 
on friday evening so I did not do anything speciall with Kontact, I did not 
move any mails or schedule a meeting or anything I just read my mails and 
answered some of them, Then I locked my KDE session and left for the 
weekend.

When I arrived monday morning I had this problem. After restarting Kontact 
and running it now again all working day it seems pretty stable again(I had 
got 2 mails during the time I was gone so).

>From: Carsten Burghardt <burghardt@kde.org>
>Reply-To: 88427@bugs.kde.org
>To: khadjari@hotmail.com
>Subject: [Bug 88427] Kontact or Kmail has a memory leak! Date: 30 Aug 2004 
>08:40:50 -0000
>
>------- You are receiving this mail because: -------
>You reported the bug, or are watching the reporter.
>
>http://bugs.kde.org/show_bug.cgi?id=88427
>
>
>
>
>------- Additional Comments From burghardt kde org  2004-08-30 10:40 
>-------
>This is pretty hard to debug with this explanation. You could check from 
>time to time if kmail is allocating more memory after certain actions (e.g. 
>moving mails).

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Comment 3 Arkadiusz Miskiewicz 2004-10-26 23:55:38 UTC
I'm currently hitting repeatable memory leak (memory usage grows very fast in matter of 2 minutes) in kde 3.3.1 with cvs patches from KDE_3_3_BRANCH (taken few days ago).

My whole maildir is less than 50MB while usage grows up to 8XX MB :/

strace reports:
19042 write(2, "kmail: parseMsg(KMMessage* aMsg == aMsg )\n", 42) = 42
19042 write(2, "kmail: + Text/Plain\n", 20) = 20
19042 write(2, "kmail:       Inserting one item into MimePartTree\n", 50) = 50
19042 write(2, "kmail:                 Content-Type: Text/Plain\n", 48) = 48
19042 gettimeofday({1098827152, 361210}, NULL) = 0
19042 write(2, "kmail: partNode::findType() is looking at Text/Plain\n", 53) = 53
19042 time([1098827152])                = 1098827152
19042 write(2, "kmail: final presence: \'\'\n", 26) = 26
19042 time([1098827152])                = 1098827152
19042 write(2, "kmail: ObjectTreeParser::parseObjectTree( node OK, showOnlyOneMimePart: FALSE )\n", 80) = 80
19042 mmap2(NULL, 33558528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb236c000
19042 mmap2(NULL, 20508672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb0fdd000
19042 mmap2(NULL, 20508672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xafc4e000
19042 munmap(0xb0fdd000, 20508672)      = 0
19042 write(2, "kmail: Unknown codec \"7bit\" requested!\n", 39) = 39
19042 mmap2(NULL, 20508672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb0fdd000
19042 write(2, "kmail: Unknown codec \"7bit\" requested!\n", 39) = 39
19042 mmap2(NULL, 20508672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xae8bf000
19042 mmap2(NULL, 41017344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xac1a1000
19042 munmap(0xae8bf000, 20508672)      = 0
19042 mmap2(NULL, 20508672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xae8bf000
19042 mmap2(NULL, 41017344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa9a83000
19042 brk(0x8715000)                    = 0x8715000
19042 mmap2(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa9a42000
19042 brk(0x86fd000)                    = 0x86fd000
19042 mmap2(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa99c1000
19042 munmap(0xa9a42000, 266240)        = 0
19042 mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa98c0000
19042 munmap(0xa99c1000, 528384)        = 0
19042 mmap2(NULL, 1576960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa973f000
19042 munmap(0xa98c0000, 1052672)       = 0
19042 mmap2(NULL, 2101248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa953e000
19042 munmap(0xa973f000, 1576960)       = 0
19042 mmap2(NULL, 3149824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa923d000
19042 munmap(0xa953e000, 2101248)       = 0
19042 mmap2(NULL, 4198400, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa8e3c000
19042 munmap(0xa923d000, 3149824)       = 0
19042 mmap2(NULL, 6295552, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa883b000
19042 munmap(0xa8e3c000, 4198400)       = 0
19042 mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa803a000
19042 munmap(0xa883b000, 6295552)       = 0
19042 mmap2(NULL, 12587008, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa7439000
19042 munmap(0xa803a000, 8392704)       = 0
19042 mmap2(NULL, 16781312, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa6438000
19042 munmap(0xa7439000, 12587008)      = 0
19042 mmap2(NULL, 25169920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa4c37000
19042 munmap(0xa6438000, 16781312)      = 0
19042 mmap2(NULL, 33558528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa2c36000
19042 munmap(0xa4c37000, 25169920)      = 0
19042 mmap2(NULL, 50335744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x9fc35000
19042 munmap(0xa2c36000, 33558528)      = 0
19042 mmap2(NULL, 67112960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x9bc34000
19042 munmap(0x9fc35000, 50335744)      = 0
19042 mmap2(NULL, 100667392, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x95c33000
19042 munmap(0x9bc34000, 67112960)      = 0

and here I killed it. It's only ~100MB but it grows up until 8XXMB and machine starts being unresponsible (it has only 512 MB RAM).

It's Linux 2.6.10rc1 at this moment, glibc 2.3.4.
Comment 4 Arkadiusz Miskiewicz 2004-10-27 00:28:49 UTC
Created attachment 8047 [details]
Mail which causes very fast eating memory by kmail
Comment 5 Arkadiusz Miskiewicz 2004-10-27 00:30:24 UTC
Take that attachment (8047), uncompress it, close kmail, put attachment in some kmail maildir, start kmail, try to open folder which contains that attachment. Hugh memory usage in very short time.
Comment 6 Arkadiusz Miskiewicz 2004-10-27 00:48:52 UTC
The file name was: 1098744724.12360.qWs28:2,S (some people are asking).
Comment 7 Anne-Marie Mahfouf 2004-10-27 00:54:20 UTC
I tried to see what's going on after arekm went on IRC twice about that bug but I don't understand what to do. I asked him to send the memory-consuming mail but he said he could not. I leave my KMail running for the whole night quite often and I don't notice anything weird.
Comment 8 Boyan Ivanov 2004-12-16 20:13:11 UTC
I don't know if this bug report is the right place,but I couldn't find a better one.I'm using kmail 1.7.1 on Qt: 3.3.3 and KDE: 3.3.1.When I try to download about 70 messages from my IMAP server kmail increases its memory usage till it reaches 700 MB (I have just 256 MB RAM + swap (around 512) and then crashes.Unfortunately I don't have a backtrace,because the program runs every time I start my session.The messages I'm trying to download are simple jpg files,none of which is bigger than 500 kb.And by downloading I mean "saving the attachments" which I do right clicking on the selected messages.
I think that's all I can say for now.
 
Comment 9 Boyan Ivanov 2004-12-16 23:28:43 UTC
Created attachment 8696 [details]
Kmail line in ksysguard
Comment 10 Boyan Ivanov 2004-12-16 23:29:36 UTC
Well,I made it crash again,but in vain.Kmail didn't show a single line about the crash.All I saw was :
tindor@boyan:/home/kde$ kmail: WARNING: KMMessagePart::setCharset(): trying to set a charset for a non-textual mimetype.
kmail: Fix this caller:
kmail: ====================================================================
kmail:
kmail: ====================================================================
kmail: WARNING: KMMessagePart::setCharset(): trying to set a charset for a non-textual mimetype.
kmail: Fix this caller:
kmail: ====================================================================
kmail:
kmail: ====================================================================

tindor@boyan:/home/kde$ 

Also I'll attach a snapshot of the ksysguard.It was made 15 minutes before the crash,but still it shows a great quantity of RAM and swap used.
Comment 11 Felix Seeger 2006-09-19 23:51:00 UTC
I also like to attach my problem to this bugreport. I am using kmail 1.9.4 on KDE 3.5.4 daily at work. Sometimes kmails size goes up to 1GB (ps aux says so).

Before you say, ps is wrong. The system shows all problem if you have less memory, after quitting kmail, free shows the freed mem, applications are able to start and the desktop is fast again.


I get this problem after running kmail many days, sometime it takes a week, sometimes only some days. I am using an Exchange 5.5 pop server, checking for mails every 1 minute. There are also many filters, sorting the mails into my folders.

Is there method to see what is going on and help debugging ? I have this problem in kmail alone and in kontakt.
Comment 12 Julien Aubin 2007-01-21 17:52:48 UTC
I also encounter the problem. Actually I think it comes from the receive message function from kmail.

I use the following configuration :
1/ Retrieve emails every minute from server,
2/ Mail analyzing through SpamAssassin and Bogofilter,
3/ Antivirus : f-prot which scans every email.

The fact is that almost every time the automatic mail retrieving process runs, the memory usage of Kontact grows up. But when I perform this check manually it does not always occur, but quite often anyway.
The function to look at is located in the mail retrieving process. Since this bug does not always occur, it may be quite hard to debug.

My configuration :
Athlon XP 1800+,
1 GB RAM,
KDE 3.5.5 and Kmail 1.9.5.

It seems that the situation is somewhat better than what it was in the first post, since when I have kontact that runs one whole weekend, the memory usage goes from 125 MB at startup to 160 MB at the end of the weekend.
Comment 13 Jaime Torres 2009-12-19 23:35:52 UTC
I guess this has been solved in kmail 1.13.0 (from kde 4.4). Thomas fixed a gigantic memory leak.
Comment 14 Björn Ruberg 2010-03-06 15:10:15 UTC
Can someone test whether this is still a problem in KDE 4.4?
Comment 15 Björn Ruberg 2010-03-06 15:10:47 UTC
*** Bug 208307 has been marked as a duplicate of this bug. ***