Memory leak in notify-osd

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.

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

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...

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.

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

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)

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

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

Marking the upstream bug fixed released too.

ISame problem in ubuntu lucid RC1.

Whatch the duplicate #569909 for full system info.

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.

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.

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

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.

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

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.

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