Memory leak in update-notifier-kde

Bug #289264 reported by Julien Aubin
98
This bug affects 13 people
Affects Status Importance Assigned to Milestone
update-notifier-kde (Ubuntu)
Fix Released
High
Jonathan Riddell
Nominated for Karmic by Stefan Fleiter

Bug Description

Binary package hint: update-notifier-kde

I've seen a memory leak in update-notifier-kde package. Each time you update the package list with the aptitude update method, the memory used by the process increases but never decreases then.

How-to-reproduce :
----------------------------------------
DO: launch the update-notifier-kde process
DO: run top or htop and sort processes upon the used memory.
DO: launch several times an aptitude update command.
You can run the following command as root in order to save time :
for i in `seq 1 50`; do sudo aptitude update; done
EXPECT: the memory used by the update-notifier-kde process increases a lot, more than 100 MB used at the end of the for loop !!!

The issue should have a very low impact in most of the cases, but for a production machine that runs 24/7 this can become resource-critical.

Release used :
Kubuntu 8.10
Package revision : 0.9

I suspect the issue from coming from one of the following lines (my knowledge of Python is NONE ;-) ) :

Line 103: self.new_dist = metaRelease.new_dist // Any garbage connection of the old new_dist reference if any ?
Line 124: self.new_dist = metaRelease.new_dist // Same comment

Tags: pet-bug
Revision history for this message
vlk (palo-bielyvlk) wrote :

I see the same problem.. I thing, after four updates is 90MB too much for one small application.

Revision history for this message
Daiwai (daiwai) wrote :

Confirmed. Kubuntu was running for about 13 days and the update-notifier-kde process used more than 230M at the end.

vlk (palo-bielyvlk)
Changed in update-notifier-kde:
status: New → Confirmed
Revision history for this message
Hervé Fache (rvfh) wrote :

I did not look at the startup memory usage, but found this bug when trying to report this program is (after plasma) the greediest on my system:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21946 herve 20 0 135m 66m 18m S 0 6.6 16:28.16 /usr/binplasma
21995 herve 39 19 116m 51m 19m S 0 5.1 0:35.93 python /usr/bin/update-notifier-kde

I think 51 MB of residual memory is a tad too much for an applet...

Revision history for this message
Hervé Fache (rvfh) wrote :

And this is after logout/logon:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29856 herve 39 19 109m 43m 28m R 100 4.3 0:03.26 python /usr/bin/update-notifier-kde
29852 herve 20 0 83768 29m 18m S 0 2.9 0:00.52 python /usr/bin/printer-applet
29807 herve 20 0 97740 25m 17m S 0 2.6 0:01.53 /usr/bin/plasma

Wow! 43 MB still!!! And 29 for the printer applet, in front of Plasma!
Let's check again when 4.2 Beta 1 is available.

Revision history for this message
Yevgen Antimirov (turist) wrote :

My `top` from 17 days-uptime machine:

6916 yevgen 39 19 197m 124m 22m S 0 3.8 1:17.20 python /usr/bin/update-notifier-kde

Guys, please please check what's wrong with it. Thanks!

Revision history for this message
Hervé Fache (rvfh) wrote : Re: [Bug 289264] Re: Memory leak in update-notifier-kde

Mine after 1 day, 17:56:
4674 fache 39 19 130m 63m 21m S 0 3.4 0:38.34 python
/usr/bin/update-notifier-kde

Not bad either, huh?

Jonathan Riddell (jr)
Changed in update-notifier-kde:
assignee: nobody → jr
Revision history for this message
Julien Aubin (gojulgarbmail) wrote :

The issue also applies to Jaunty :
Currently the process is eating almost 100 MBs of memory.

Revision history for this message
Daniel Hahler (blueyed) wrote :

This appears to be caused by apt_check / apt_check.run().

Exchanging
            result = apt_check.run()
with
            result = (0, 0)
in /usr/bin/update-notifier-kde prevents this growth of memory usage (there's minor growing still though - according to ps).

apt_check is in /usr/lib/update-notifier/apt_check.py (from update-notifier-common).

I've quickly looked into it: it used apt_pkg, which may be causing it.

btw: a comment in update-notifier-kde says that the whole checkNewPackages may not be required in the future:
 checkNewPackages = True #kpackagekit has a new package notifier but it's broken so use this

Looks like some memory profiling is required here.

Changed in update-notifier-kde (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
Daniel Hahler (blueyed) wrote :

btw: I've added the following snippet (in variants) to debug this (and added output to update-notifier-kde):
(update-notifier-kde &); sleep 5; pid=$(pgrep -f ^python.*update-notifier); echo $pid; for i in `seq 1 50`; do ps aux|grep update-notifier|grep -v grep|grep python|awk '{print $2":"$5"/"$6}'; sudo touch /var/lib/apt/lists/; sleep 15; done; kill $pid

This may help you, apart that a "real profiler" is more useful of course, see e.g. http://stackoverflow.com/questions/110259/python-memory-profiler

Revision history for this message
Gobnuts (gobnuts) wrote :

I experience the same problem on Jaunty with KDE 4.3RC1.
running apt-get update and apt-get upgrade twice makes update-notifier-kde rack up around 200 MB of Ram (everytime I run it, update... takes in a few more MBs. Also for a couple of minutes it insane amounts of CPU time (in the high 70s to 80s initially, the between 20 and 50% for another couple of minutes).

Now, on my main machine it not that big of a deal, but on weaker machines this is really annoying as this almost causes the system to come to a grinding halt.
If there is a fix out for karmic already it would be nice to have this backported to Jaunty.

Revision history for this message
Daniel Hahler (blueyed) wrote :

I'm raising the priority to High, since it's really bad for long running systems (that e.g. only get suspended / hibernated).

If this cannot get fixed properly, I think a workaround should get implemented to regularly restart the app.

Changed in update-notifier-kde (Ubuntu):
importance: Medium → High
Revision history for this message
Julien Aubin (gojulgarbmail) wrote :

In the worst case, you can kill the process yourself. It should restart after the next sudo aptitude update.

Revision history for this message
Götz Christ (g-christ) wrote :

The big memory leak is still present in version 0.19 of Jaunty.

As a workaround until this is fixed, how can I disable update-notifier-kde so that it doesn't start every time?

Revision history for this message
BongoMan (pascal-bongosoft) wrote :

I observe this bug too in jaunty 64 bit. Here what top says after only 1/2 hour uptime and one "apt-get update":

4620 pp 39 19 435m 139m 25m S 0 4.7 2:13.41 python /usr/bin/update-notifier-kde

whaow...

Note that after running "apt-get update", update-notifier-kde had high cpu usage (nice time) during 2-3 minutes. This could have to do with a big KDE update today, but should not happen...

> how can I disable update-notifier-kde so that it doesn't start

I would be interested in this too...

Revision history for this message
myrtille (akm1984) wrote :

Hi,

I think you can disable it by starting KPackageKit, go to settings ->Edit Software Sources->Updates and in Automatic updates uncheck "check for updates".

Revision history for this message
Götz Christ (g-christ) wrote :

@myrtille: you are right, thanks for the tip!

But in Karmic I have seen that update-notifier-kde uses less memory, between 20-35 MB. Right now it uses 5 MB (RSS 15 MB)

Revision history for this message
dtr (dtr) wrote :

I've noticed this for some time now, I'm using Kubuntu 9.04 64 bit.
Today the update-notifier-kde is using 217 MB long after I checked for updates. If I don't kill the process it remains until either shut-down or reboot.

Revision history for this message
myrtille (akm1984) wrote :

G.Christ I can confirm.
Looks as if this is fixed in Karmic. I ran the loop of the initial post on an up to date karmic and update-notifier "only" uses ~30Mb. On jaunty I had it using up to and above 400Mb of RAM on the same PC.

Changed in update-notifier-kde (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.