Memory leak in notify-osd

[Yang]

Binary package hint: notify-osd

Ever since upgrading to Ubuntu 9.10, I found that these programs, which I believe are closely related, leak a lot of memory over time:

/usr/lib/notify-osd/notify-osd
/usr/lib/indicator-applet/indicator-applet --oaf-activate-iid=OAFIID:GNOME_IndicatorApplet_Factory --oaf-ior-fd=32

E.g., after a day, each of the above consumes many hundreds of MB in the resident set size (and even more in the virtual memory size). I usually just send SIGTERM to both; after killing notify-osd, I am prompted to restart the program (don't quite remember what the dialog box says, but the button to hit is Reload). The programs restart with small memory usage again.

Not sure if it matters, but I use Pidgin, and I leave it running all the time. My understanding is that notify-osd is the program that draws those pop-up notifications whenever signs on/off, and AFAIK Pidgin is the only program that I ever see these pop-up notifications from.

$ lsb_release -rd
Description: Ubuntu 9.04
Release: 9.04

$ uname -a
Linux yang-xps410 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux

$ apt-cache policy notify-osd
notify-osd:
  Installed: 0.9.11-0ubuntu3
  Candidate: 0.9.11-0ubuntu3
  Version table:
 *** 0.9.11-0ubuntu3 0
        500 http://us.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

[Michael Kuhn (suraia)]

I can confirm this. It seems to happen when notify-osd displays icons in the bubble:

I am using Banshee, which displays notifications with album art on track changes. One album cover is about 1.7 MB in size. This causes notify-osd to use about 10 MB more on _each_ track change when listening to this album. I tried reproducing this with notify-send -i /path/to/cover.jpg, but it does not work.

[Alexander Sack (asac)]

this is a release blocker; notify-osd grows to 587m 356m within less than a day (maybe even 5 hours?):

$ ps auxw | grep notify-osd | grep -v gre
asac 24967 0.9 17.7 602272 365576 ? S 12:22 2:52 /usr/lib/notify-osd/notify-osd
$ uptime
 17:14:45 up 19:41, 6 users, load average: 0.04, 0.04, 0.00
$ date
Mon Jul 27 17:13:54 CEST 2009

[Alexander Sack (asac)]

i ran valgrind to get an initial idea. test: search for google in gwibber, wait for about 12 notifications, get this:

First a few probably obvious leaks (stripped a bit); further down the full valgrind output.

==16630==
==16630==
==16630== 58,336 (15,360 direct, 42,976 indirect) bytes in 23 blocks are definitely lost in loss record 202 of 218
==16630== at 0x4C279E1: realloc (vg_replace_malloc.c:429)
==16630== by 0xA85701B: FcPatternObjectInsertElt (fcpat.c:358)
==16630== by 0xA857ADC: FcPatternObjectAddWithBinding (fcpat.c:515)
==16630== by 0xA84D12F: FcDefaultSubstitute (fcdefault.c:136)
==16630== by 0xA180A9A: (within /usr/lib/libpangoft2-1.0.so.0.2400.5)
==16630== by 0x7031F18: pango_context_get_metrics (in /usr/lib/libpango-1.0.so.0.2400.5)
==16630== by 0x4192E1: defaults_constructed (defaults.c:409)
==16630== by 0x7274DE2: g_object_newv (in /usr/lib/libgobject-2.0.so.0.2104.0)

==16630==
==16630==
==16630== 27,616 (2,368 direct, 25,248 indirect) bytes in 8 blocks are definitely lost in loss record 205 of 218
==16630== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==16630== by 0x6DAF303: (within /usr/lib/libcairo.so.2.10800.8)
==16630== by 0x6DAF657: (within /usr/lib/libcairo.so.2.10800.8)
==16630== by 0x412776: _refresh_background (bubble.c:517)
==16630== by 0x41373E: bubble_recalc_size (bubble.c:3268)
==16630== by 0x41AFA9: stack_notify_handler (stack.c:645)
==16630== by 0x41A095:

==16630== 1,362,696 (54,552 direct, 1,308,144 indirect) bytes in 39 blocks are definitely lost in loss record 217 of 218
==16630== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==16630== by 0x74ED187: g_malloc0 (in /usr/lib/libglib-2.0.so.0.2104.0)
==16630== by 0x41D2D7: tile_new (tile.c:56)
==16630== by 0x4118F6: _refresh_icon (bubble.c:780)
==16630== by 0x411CD9: bubble_set_icon (bubble.c:2249)
==16630== by 0x41B0CA: stack_notify_handler (stack.c:617)
==16630== by 0x41A095: dbus_glib_marshal_stack_VOID__STRING_UINT_STRING_STRING_STRING_BOXED_BOXED_INT_POINTER (stack-glue.h:100)

Here the full:

==16630== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 14 from 2)
==16630== malloc/free: in use at exit: 4,703,720 bytes in 13,166 blocks.
==16630== malloc/free: 79,139 allocs, 65,973 frees, 13,398,848 bytes allocated.
==16630== For counts of detected errors, rerun with: -v
==16630== searching for pointers to 13,166 not-freed blocks.
==16630== checked 3,839,584 bytes.
==16630==
==16630== 9 bytes in 1 blocks are definitely lost in loss record 8 of 218
==16630== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==16630== by 0xA859A93: FcStrCopy (fcstr.c:42)
==16630== by 0xA85CFD4: FcEndElement (fcxml.c:1936)
==16630== by 0xCBEAC52: (within /usr/lib/libexpat.so.1.5.2)
==16630== by 0xCBEBB93: (within /usr/lib/libexpat.so.1.5.2)
==16630== by 0xCBED709: (within /usr/lib/libexpat.so.1.5.2)
==16630== by 0xCBEDE2A: (within /usr/lib/libexpat.so.1.5.2)
==16630== by 0xCBE4040: XML_ParseBuffer (in /usr/lib/libexpat.so.1.5.2)
==16630== by 0xA85B4F8: FcConfigParseAndLoad (fcxml.c:2552)
==16630== by 0xA85B7DD: FcConfigParseAndLoad (fcxml.c:2438)
==16630== by 0xA85CC...

[Alexander Sack (asac)]

patch that potentially fixes tile memleaks in bubble.c - which should be the biggest cake from this huge memleak; also refactor "tile" memory to make it easier to copy code in future.

[Alexander Sack (asac)]

fix available in branch attached. merge requested into lp:notify-osd: https://code.edge.launchpad.net/~asac/notify-osd/lp378193_tile_memleak/+merge/9326

[Alexander Sack (asac)]

i can confirm that the huge tile block mem leak is gone after the patch:

==16630== 1,362,696 (54,552 direct, 1,308,144 indirect) bytes in 39 blocks are definitely lost in loss record 217 of 218
==16630== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==16630== by 0x74ED187: g_malloc0 (in /usr/lib/libglib-2.0.so.0.2104.0)
==16630== by 0x41D2D7: tile_new (tile.c:56)
==16630== by 0x4118F6: _refresh_icon (bubble.c:780)
==16630== by 0x411CD9: bubble_set_icon (bubble.c:2249)
==16630== by 0x41B0CA: stack_notify_handler (stack.c:617)
==16630== by 0x41A095: dbus_glib_marshal_stack_VOID__STRING_UINT_STRING_STRING_STRING_BOXED_BOXED_INT_POINTER (stack-glue.h:100)

[Launchpad Janitor (janitor)]

This bug was fixed in the package notify-osd - 0.9.15-0ubuntu2

---------------
notify-osd (0.9.15-0ubuntu2) karmic; urgency=low

  (cherry-pick rev 357 from lp:~asac/notify-osd/lp378193_tile_memleak)
  * fix LP: #378193 - huge memory leak in notify-osd; turned out the biggest share of
     memory leak was due to tile objects not properly destroyed in bubble.c; refactoring code a bit
     to prevent this in future
     - update src/bubble.c

 -- Alexander Sack <email address hidden> Mon, 27 Jul 2009 17:53:28 +0200

[Alexander Sack (asac)]

i filed a new bug 405364 for the leak that is left after this.

[David Barth (dbarth)]

Marking the upstream bug fixed released too.

[Emanuele Rampichini (emanuele-rampichini-gmail)]

ISame problem in ubuntu lucid RC1.

[Emanuele Rampichini (emanuele-rampichini-gmail)]

Whatch the duplicate #569909 for full system info.

[Russ K. (x87bliss)]

I am adding libnotify support to a program, and I was using the following function to set the icon:

notify_notification_set_icon_from_pixbuf

While using the program, notify-osd climbed to over 1GB of memory used. Everytime the notification was updated, the memory usage grew.

I commented out the 'notify_notification_set_icon_from_pixbuf' line, and now have an iconless notification. With that, the memory stays at 3.3MB while a notification is displayed, then drops down to 2.9MB after the notification fades away.

[Dan McCombs (overridex)]

I can confirm the memory leak in 10.04 as well, growing to over 1GB of memory over time, obviously depending how many notifications are displayed.

[Guillaume Mazoyer (respawneral)]

Leak confirmed here too on a fresh installation of Lucid (less than a week). Over 300 Mio after 3 days without reboot.

[Mike Barker (msb-msbarker)]

Leak also confirmed here on both upgrades and fresh installations (two laptops and three workstations). Memory climbs with each notification until I have to reboot because of memory consumption.

[Sebastien Bacher (seb128)]

could those still having an issue in lucid open a new bug with a valgrind log rather than comment on a closed bug?

[Karl Lattimer (karl-qdh)]

Anyone wishing to add further, more up to date valgrind reports on this bug should do so on bug #610389 instead.
This specific issue is considered fixed, but it is expected there may be a few more in need of fixing.

[nh2 (nh2)]

Newer bug like this, still affecting at least Ubuntu 16.04: #725435