Bug 347240 - KMail does not release memory
Summary: KMail does not release memory
Status: RESOLVED FIXED
Alias: None
Product: kmail2
Classification: Applications
Component: general (show other bugs)
Version: Git (master)
Platform: openSUSE Linux
: NOR major
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-05 15:29 UTC by Raymond Wooninck
Modified: 2015-05-20 13:29 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
heaptrack file (79.43 KB, application/octet-stream)
2015-05-07 14:48 UTC, Raymond Wooninck
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Raymond Wooninck 2015-05-05 15:29:24 UTC
I just started kmail and looked at a couple of emails. Checking the memory, it seems that KMail is using 1.1Gb of memory.  Clicking on a new folder with emails or an email itself seems to increase the memory usage. However this seems only to be released when kmail is closed.

With ksysguard, I get the following information for kmail :
Process 3494 - kmail

Summary

The process kmail (with pid 3494) is using approximately 1.1 GB of memory.
It is using 1.1 GB privately, and a further 83.1 MB that is, or could be, shared with other programs.
Dividing up the shared memory between all the processes sharing that memory we get a reduced shared memory usage of 15.3 MB. Adding that to the private usage, we get the above mentioned total memory footprint of 1.1 GB.
Library Usage

The memory usage of a process is found by adding up the memory usage of each of its libraries, plus the process's own heap, stack and any other mappings, plus the stack of its 7 threads. 
Private
more
1134320 KB	[heap]
3268 KB	/usr/lib64/libQt5WebKit.so.5.4.2
2464 KB	/usr/lib64/libQt5WebEngineCore.so.5.4.2
2124 KB	/usr/lib64/libkmailprivate.so.4.75.0
1008 KB	/usr/share/icu/54.1/icudt54l.dat
Shared
more
13516 KB	/usr/lib64/libQt5WebKit.so.5.4.2
3976 KB	/usr/lib64/libQt5Widgets.so.5.4.2
3840 KB	/usr/lib64/libQt5Core.so.5.4.2
3732 KB	/usr/lib64/libQt5Gui.so.5.4.2
3568 KB	/SYSV00000000 (deleted)
Totals

Private	1157388 KB	(= 13152 KB clean + 1144236 KB dirty)
Shared	85096 KB	(= 81448 KB clean + 3648 KB dirty)
Rss	1242484 KB	(= Private + Shared)
Pss	1173061 KB	(= Private + Shared/Number of Processes)
Swap	0 KB

Reproducible: Always

Steps to Reproduce:
1. Start kmail 
2. open ksysguard 
3. start clicking on emails (email shown in preview window)

Actual Results:  
Memory usage increases and increases

Expected Results:  
Memory usage should not really increase or slightly and released again after some time.

All kdepim components are based on git master.
Comment 1 Raymond Wooninck 2015-05-07 12:44:39 UTC
I have tried two different setups (with and without Preview Pane), but the result remains the same. 

The memory usage of kmail is increased by the amount of memory required to display the email itself. Even if the case where the email is only displayed in a separate window (setup without preview), the memory is not released after closing this window. 

The memory is only being released once kmail itself is being closed.
Comment 2 Sergio Martins 2015-05-07 13:25:40 UTC
can you get a massif or heaptrack trace ?
Comment 3 Raymond Wooninck 2015-05-07 14:48:26 UTC
I tried to use massif, but this was killing the system and I wasn't really able to click on a number of emails. 

I then switched to heaptrack and I have attached the logfile.  I have "previewed" about 30 emails and the total memory consumption as reported by ksysguard was around 1.4Gb for kmail.
Comment 4 Raymond Wooninck 2015-05-07 14:48:56 UTC
Created attachment 92479 [details]
heaptrack file
Comment 5 Raymond Wooninck 2015-05-20 13:29:52 UTC
I didn't checked the memory usage for some time and with the latest snapshot from git master, the memory usage has been heavily reduced and seems to be stable. Opening a folder and then an email will increase the memory, but when a smaller email is then selected the memory usages goes down (which is expected behavior). 

Closing the bug as resolved.