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.
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).
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
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.
Created attachment 8047 [details] Mail which causes very fast eating memory by kmail
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.
The file name was: 1098744724.12360.qWs28:2,S (some people are asking).
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.
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.
Created attachment 8696 [details] Kmail line in ksysguard
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.
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.
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.
I guess this has been solved in kmail 1.13.0 (from kde 4.4). Thomas fixed a gigantic memory leak.
Can someone test whether this is still a problem in KDE 4.4?
*** Bug 208307 has been marked as a duplicate of this bug. ***