dbus-related memory leakings

[bebehei]

Running valgrind --leak-check=full --show-leak-kinds=definite --track-origins=yes ~/code/dunst/dunst shows that the GDBus*-Types are not freed correctly. There are multiple issues with this.

This may be either a glib-related bug in the g_*_unref() functions or it might be a problem in our handling of dbus-related stuff:

(0) This is output for a single message with a raw icon (generated from spotify):

==23036== 270,677 (40 direct, 270,637 indirect) bytes in 1 blocks are definitely lost in loss record 1,882 of 1,883
==23036==    at 0x4C2CE5F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23036==    by 0x6E01E38: g_malloc (gmem.c:94)
==23036==    by 0x6E199B5: g_slice_alloc (gslice.c:1025)
==23036==    by 0x6E385BD: g_variant_alloc (gvariant-core.c:476)
==23036==    by 0x6E385BD: g_variant_new_from_children (gvariant-core.c:565)
==23036==    by 0x6E35293: g_variant_builder_end (gvariant.c:3703)
==23036==    by 0x59DFF15: parse_value_from_blob (gdbusmessage.c:1823)
==23036==    by 0x59E00BE: parse_value_from_blob (gdbusmessage.c:1854)
==23036==    by 0x59DFD28: parse_value_from_blob (gdbusmessage.c:1774)
==23036==    by 0x59DFFFC: parse_value_from_blob (gdbusmessage.c:1727)
==23036==    by 0x59DFEDE: parse_value_from_blob (gdbusmessage.c:1808)
==23036==    by 0x59E2143: g_dbus_message_new_from_blob (gdbusmessage.c:2148)
==23036==    by 0x59EC79D: _g_dbus_worker_do_read_cb (gdbusprivate.c:744)

270kB per notification. That saying: If you listen to spotify for 10 hours (3min/track), you've got about 50MBs leaked just for listening to spotify.

(1) Some other (smaller) stuff from the same notification:

==23036== 81 (40 direct, 41 indirect) bytes in 1 blocks are definitely lost in loss record 1,254 of 1,883
==23036==    at 0x4C2CE5F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23036==    by 0x6E01E38: g_malloc (gmem.c:94)
==23036==    by 0x6E199B5: g_slice_alloc (gslice.c:1025)
==23036==    by 0x6E384EC: g_variant_alloc (gvariant-core.c:476)
==23036==    by 0x6E384EC: g_variant_new_from_bytes (gvariant-core.c:512)
==23036==    by 0x6E316F6: g_variant_new_from_trusted (gvariant.c:321)
==23036==    by 0x6E317CE: g_variant_new_byte (gvariant.c:410)
==23036==    by 0x59DF92D: parse_value_from_blob (gdbusmessage.c:1486)
==23036==    by 0x59E00BE: parse_value_from_blob (gdbusmessage.c:1854)
==23036==    by 0x59DFD28: parse_value_from_blob (gdbusmessage.c:1774)
==23036==    by 0x59DFFFC: parse_value_from_blob (gdbusmessage.c:1727)
==23036==    by 0x59DFEDE: parse_value_from_blob (gdbusmessage.c:1808)
==23036==    by 0x59E2143: g_dbus_message_new_from_blob (gdbusmessage.c:2148)

(2) sending a notification with a hint produces this (and additonally 1):

==23428== 168 (80 direct, 88 indirect) bytes in 2 blocks are definitely lost in loss record 1,645 of 1,910
==23428==    at 0x4C2CE5F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23428==    by 0x6E01E38: g_malloc (gmem.c:94)
==23428==    by 0x6E199B5: g_slice_alloc (gslice.c:1025)
==23428==    by 0x6E384EC: g_variant_alloc (gvariant-core.c:476)
==23428==    by 0x6E384EC: g_variant_new_from_bytes (gvariant-core.c:512)
==23428==    by 0x6E316F6: g_variant_new_from_trusted (gvariant.c:321)
==23428==    by 0x6E3185D: g_variant_new_int32 (gvariant.c:485)
==23428==    by 0x59DFAB7: parse_value_from_blob (gdbusmessage.c:1516)
==23428==    by 0x59E00BE: parse_value_from_blob (gdbusmessage.c:1854)
==23428==    by 0x59DFD28: parse_value_from_blob (gdbusmessage.c:1774)
==23428==    by 0x59DFFFC: parse_value_from_blob (gdbusmessage.c:1727)
==23428==    by 0x59DFEDE: parse_value_from_blob (gdbusmessage.c:1808)
==23428==    by 0x59E2143: g_dbus_message_new_from_blob (gdbusmessage.c:2148)

There's still more.

---

@tsipinakis Do you know, how to debug this? I don't see, where this pointer from g_dbus_message_new_from_blob get's passed to. I don't see any possibility to examine this.

[bebehei]

According to glib docs, g_variant_lookup_value transfers full. So we have a missing unref in dbus.c, right?

[bebehei]

Related or even duplicate of #251

[bebehei]

I'm working currently on this, see my dbus-leakings branch.

The commit bebehei/dunst@3fcf75f does the stuff somewhat right, but I get quirky numbers, which I don't understand:

I have 8GB of RAM and the image.jpeg is 316K big.

I'm testing with for i in {0..1000}; do dunstify --raw_icon=image.jpeg $i b; done. After this command finishes, roughly 980 notifications are left in the queue. I close them all with the close_all keyboard shortcut.

This is the result: (poorly read via htop during runtime)

branch	master	dbus-leakings
mem consumption with full queue	67,1%	33,7%
mem consumption after emptying queue	34,1%	33,7%

What? Why is does master free some data, but dbus-leakings not?

Obviously, both branches have their problems with raw icons:

I'm testing now with for i in {0..1000}; do dunstify --icon=$PWD/image.jpeg $i b; done (mind that I only send now the icon string). It still shows the image, but dunst reads it manually of the harddrive:

branch	master	dbus-leakings
mem consumption with full queue	0,3%	0,3%
mem consumption after emptying queue	0,3%	0,3%

[bebehei]

I believe, I understand the quirky numbers now.

So, there has to be some other memory leak. I've verifyfied, that the notifications actually get freed, etc. The question I couldn't answer was: Is there a case, where we have hit glibc's implementation details and (g_)free() does not always free?

And it turns out: yes.

As the above testcase always adds notifications, the datasegment increases constantly. At the end of the case, all notifications get freed, except for the last ones in history. And those sit right there. The memory allocator can never decrease the datasegment. So it never can "give memory back" until these notifications are freed.

So test it differently: Let's use a shorter timeout and have no need to buffer the notifications in waiting queue:

Running for i in {0..1000}; do dunstify --icon=$PWD/image.jpeg -t 100 $i b; done, dunst behaves differently:

• branch dbus-leakings:
  • 1.1%
• branch master:
  • 34,4%

q.e.d.

---

A 1% of RAM (80MB) for 20 notifications in history seems still to be very much. But there is nothing left to optimize in dbus handling. The other memory leaks are in x11/cairo/pango related code.

---

The only question, which is left: Adding 1000 notifications (which fill up the waiting queue), then calling move_all_to_history() and then sending the amount of history size notifications again over.

How much space will be given back after all 1000 notifications are fully freed? The amount of one notification or all space?