Dunst: Memory leak

[Strubbl]

I had run my PC incl. dunst for about a weekend. After the weekend it was using about 17 GB of memory. Unfortunately the PC is currently not running anymore.

How can i help to find the memory leak?

Installation info

• Version: Dunst - A customizable and lightweight notification-daemon 1.3.2 (2018-05-06) and also until at least 896c008def638d151517e02240f01d1198df09db
• Install type: pacman -S dunst
• Distro and version: Arch Linux

[tsipinakis]

Thanks for the report.

---

To rule out the obvious please make sure that the history_length setting is set to a value >0 else obviously dunst is keeping all notifications in memory intentionally (including icons, which can get quite big)

If not, continue on.

---

To start of, please build from source to ensure that the leak hasn't been fixed in the meantime and most importantly that debug symbols are included in the build (they are by default but some distros strip them off)

After that you should install valgrind and run the compiled binary like so:

valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --verbose --log-file=valgrind-log ./dunst

and upload the resulting valgrind-log file after leaving it running for a while until the memory usage racks up again. The more memory you let it use the more obvious the culprit will be since there will probably be quite a few of false positives in that file, try to see what notifications make it leak.

(Note: Make sure to gracefully close it by ctrl+c or similar, not sure how often valgrind dumps the output to the log)

[Strubbl]

History length seems to be ok:

$ grep history_length ~/.config/dunst/dunstrc 
    history_length = 50

I kept valgrind running for about 8 hours and it reached over 20 GB again. Here is the valgrind log of that session:
https://gist.github.com/Strubbl/13f1d3f4799fde853b62eb8d7746c421

I guess the process is getting this large memory footprint when i am away from the computer, which means i am not reading the dunst messages and they are kept.

[bebehei]

@Strubbl Thanks for the output. Is this really everything?!? The valgrind log looks like it got truncated.

[WhyNotHugo]

@Strubbl There's a link on top of the gist to the non-truncated version.

[bebehei]

Oh sorry. Github gists don't display the whole file :see_no_evil:

Could you please paste your configuration, too?

[Strubbl]

yes, my config is this one: https://gist.github.com/Strubbl/375e2551c1d82dcdba659995997dcf5d

[bebehei]

@Strubbl

Thank you for the big valgrind log. But all I can really read out of it: something with gdk-pixbuf went south. And the better thing: I can reproduce it right now, too!

I suspect a recent librsvg update in ArchLinux shipped some troublesome changes. Downgrading librsvg from [ALPM] downgraded librsvg (2:2.44.0-1 -> 2:2.42.4-1) solves the issue.

I'm currently unsure, where to report it and whether this is actually a gdk-pixbuf bug or a librsvg bug.

[tsipinakis]

Ha! That's something I wouldn't have seen for a while since debian is still on 2.40.20.

I assume it's librsvg's issue if downgrading fixes it. Best thing we could do now is try to make a test case and see how it leaks. @bebehei since you have the problematic versions in your package tracker (and compiling libraries is a pain) can you try out variations of the following program and see if it starts leaking?

int main() {
        for(int i =0; i < 1000; i++) {
               GError *error = NULL;

               GdkPixbuf *pixbuf = gdk_pixbuf_new_from_file(path, &error);

               if (error) {
                       g_error_free(error);
               }
              g_free(pifxbuf);
       }
       getchar();
}

[bebehei]

I already created a test case (similar to yours), but it doesn't show up anymore in valgrind. Edit: I've given gdk-pixbuf the wrong filenames. g_strchomp FTW!

The source problem: Between 2.42 and 2.44 are ~ 1000 commits diff.

I don't know, where to start to solve this effectively.

[bebehei]

Created an upstream bugreport and also a reproducer.

[Strubbl]

Thank you very much for your investigation.

[tsipinakis]

This should be solved with librsvg 2.44.1.

[Strubbl]

the upstream bug was reopened and it should really be solved with 2.44.2 now