GNOME Bugzilla – Bug 97527
Memory Leak when Task Manager displayed
Last modified: 2004-12-22 21:47:04 UTC
Summary Description: Pan 13.1 apparently has a memory leak when downloading news messages with the Task Manager window displayed. Increasing memory usage was observed using the 'top' command and the 'SIZE' column for Pan. Detailed Description: I observed that the my system began to slow to a crawl after downloading news messages with Pan over the course of an hour or two. When I investigated I used 'top' to watch the CPU and memory usage and noted that the size of Pan memory had grown to over 900MB (I have 1GB RAM installed) and was still gradually increasing. The swap daemon kswapd was competing with Pan for and X for the most CPU usage. I am running Pan under Mandrake 9.0 and KDE 3.0, with a 1.2 GHz Athlon processor, TNT-2 graphics card, 1GB RAM. The version of Pan I am using is from the pan-0.13.1-nospell1.i586.rpm package. I have ADSL, and Pan displays typical downloading topping out at about 90KB/s (that's kilobytes not kilobits). I have a D-Link ethernet card interface to the DSL modem. My system had become nearly unusable with the memory usage that Pan had claimed, so I killed Pan with signal 9 and restarted it. On restart I had it restore my download selection list and it began downloading messages again. It was then that I observed (using 'top') that the memory usage was climbing again, at a rate of around 4-6 MB per minute when the Task Manager was displayed. When I closed Task Manager and let Pan download, the memory utilization stabilized, though none of the previously allocated memory was released (it has stayed just below 460MB for the past couple of hours - it had to run quite a while to get up to that amount as I was trying to isolate the problem).
I changed the priority to High after reading the fields description. Yes I read the instructions after using it, like a typical red-blooded American. ;) I left the severity at major instead of critical. Even though in my judgment this is a severe memory leak, there is an easy work-around. Namely, avoiding use of the Task Manager window.
Looks like this is caused in periodic_update_timer_foreach(): we're leaking five strings per task every two seconds. Ouch. This was introduced in 0.13.1, which ports the Task Manager from the GtkCList widget to the newer GtkCTreeView. The code walks through each cell, gets the current contents, calculates the new contents, and if updates the cell if they differ. The 0.13.0 code used this cell-by-cell scheme because that's what GktCList's API permitted. However GtkCTreeView allows multiple columns to be updated in a single call, so this function can be rewritten to have 1 call (one update) rather than 5..10 (5 lookups, 0...5 updates) per task. This is more efficient, and the five leaked strings (from the lookups) will disappear as a side-effect.
Fixed in 0-13-fix: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=task-manager.c&rev1=1.88&rev2=1.88.2.1&root=/cvs/gnome and in cvs head: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=task-manager.c&rev1=1.88&rev2=1.89&root=/cvs/gnome
There is still a big memory leak when the task manager is opened. The system under test is RedHat 8.0, using the supplied RPM from the pan web site. I verified that the version of task-manager.c packaged with this (srpm, i686.rpm) is identical to the updated one in pan CVS.
Bumped remaining bugs to 0.13.3.
I don't see any signs of such a leak, and valgrind also seems happy. Could you give some more information?
don: ping
As far as I can tell, the memory leak is fully fixed in 0.13.2. The memory usage looks steady regardless of whether the task manager is open or not. I have noticed a significant performance drag when the number of items in the task manager exceeds about 1k (Pan windows body text won't even update or refresh when exposed, although the text in the window manager's bar does update), but I haven't done enough investigation to do a writeup on that. I think this bug report should be closed, and if the performance issue is a real deal, I'll open a different report for that.
*** Bug 101419 has been marked as a duplicate of this bug. ***
Interesting timing, as I've just found a second leak in the Task Manager. :) The problem finally started showing up for me in 0.13.2.92, when cached articles weren't removed from the queue until the `save attachment' task was freed. But the tasks weren't being freed... so my cache directory kept getting larger, and larger... After some digging around I found two refcount bugs in Task Manager's GtkCTreeView code to account for this. Both are described in bug 101419: http://bugzilla.gnome.org/show_bug.cgi?id=101419 And fixed in CVS here: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=task-manager.c&rev1=1.90&rev2=1.91&root=/cvs/gnome