I've observed a huge memory leak in xfce4-notifyd 0.3.0, after an application (qbittorrent) triggered a massive amount of notifications (which is faulty in itself, but that's another problem). After killing the qbitorrent process, I realised that both X and xfce4-notifyd were talking a massive amount of memory: > VIRT RES SHR Process > 8962M 6452M 6357M /usr/lib/xorg-server/Xorg -background none :0 vt01 -nolisten tcp -novtswitch -auth /var/run/lxdm/lxdm-:0.auth > 5624M 3152M 2956M /usr/lib/xfce4/notifyd/xfce4-notifyd I'm not sure how to investigate the issue further. If needed, I'm available to try and reproduce the issue. OS: Arch Linux Packages: - Xfce 4.12 - xfce4-notifyd 0.3.0 - Xorg 1.18.4
Possibly the same as: https://bugzilla.xfce.org/show_bug.cgi?id=12733. This has been fixed in the git tree.
Ah great! I will try with the latest git version.
Even with the latest version from Git, I still observe a memory leak (xfce4-notifyd has reached 480MB in less than a day). I could try running it under valgrind to see whether there is something clearly wrong.
Created attachment 6780 Valgrind log (default options), after running for some hours Valgrind shows a huge amount of "possibly lost", I guess it would be easy for a xfce4-notifyd dev to investigate the issue (I don't think any particular kind of notification triggers the issue).
Created attachment 6784 Destroy cairo surface patch It looks like the patch from bug 12733 (https://git.xfce.org/apps/xfce4-notifyd/commit/?id=26e04bf1d493e3cc6cfa28a4b010d6d74e3176a8) was inadvertently reversed with the bug 11341 (https://git.xfce.org/apps/xfce4-notifyd/commit/?id=0addd8092ca37033bff2e560b5cb6453ca339d7d) patch. Can you try this attached patch against the git tree? On my system (also Arch), after this patch I have a much smaller memory leak still present but it seems to top off after 10MB of leakage. I'll take another look to see if I can track down this elusive leak.
Wow yes there's definitely been some trouble when this later commit has been rebased! A new commit should be pushed ASAP to "revert revert" the addition of cairo_surface_destroy(). In the meantime I'll try again with cairo_surface_destroy() and see if I still observe a significant leak.
Created attachment 6785 Patches Try this patch. It fixes a number of things: - destroy cairo surface (fixes large memory leak) - GVariant fixes (fixes some minor leaks) - cleans up compilation message - fixes minor pixbuf declarations This patch seems to work well on my system. There are still some small leaks, but I can't find them. Note: you have to apply this patch against the git tree as it includes the previous patch.
Great, thanks for your work, trying now! For the record, despite using gtk 3.20 (well we both use Arch so I guess it goes without saying), I don't see any compilation warning without your patch.
Created attachment 6787 Valgrind log (--leak-check=full), debug build There still seems to be some leaks. Running under valgrind, the memory consumption reached 150 MB after just a few dozen notifications (log attached). I'm rerunning now without valgrind to see if the high memory consumption was related to valgrind itself.
Playing around with notify-send, things seem to have got better, but I still observe a leak quite easily. The xfce4-notifyd starts at around 18MB, and after running: > $ for i in {1..1000}; do notify-send "test"; done the process has already reached 30MB. Not too dramatic, especially given that the process is terminated after some time without notification, but still a clear leak.
The same test on my system: I start with RSS memory usage of 24.1 and after the 1000 notifications, I end up at 26.8. Then after a minute or so it drops to 25.2. I can't seem to locate the other memory leaks. I wonder if they are from GTK3 itself?
Retried it just after restarting the process: RSS VSS Before 9.6 420.3 After 32.1 440.2 As you suggest, I would suspect GTK3 too. Otherwise it would be hard to explain why we got so different results in terms of RSS usage. Maybe this is impacted by configuration-specific factors, such as the display size (1920x1080 for me). When firing so many notifications, they end up filling all the screen and clashing between one another, so maybe GTK doesn't handle that too well. Just a supposition.
So I investigated a bit further, and I think I've understood where the memory usage comes from. Using the same loop as before with a variable number of notifications: Nb 0 100 200 300 400 500 600 ... 1000 RSS 9.5 20.2 23.8 27.8 31.2 32.1 31.9 ... 32.5 What happens is that a little less than 400 such notifications fit in my screen. Beyond that, the memory consumption doesn't increase anymore. So it's as if buffers were allocated per coordinate, never freed and reused when redrawing at the same coordinate. Not sure how to interpret this though.
Hi, sorry, yes it seems like there was a mistake and I accidentally reverted the memleak fix. I'll review the new patch from ToZ and then push all that to master. Thanks for looking into all of this!
Created attachment 6804 Re-add cairo surface destroy patch I've done some more investigation and here are four patches, separated into groupings, that fix the issues that I've found. I haven't been able to fully fix the leaking as there is still some leakage, but these patches fix some of those issues. Here is the first.
Created attachment 6805 Fix GTK 3.20 ifdefs The second.
Created attachment 6806 Fix uninitialized pixbufs The third.
Created attachment 6807 Unreference gvariants The fourth.
ToZ: Thanks for the patches - pushed them all to master! Feel free to reopen if the memleaks resurface or if there is a problem with the patches.
Great, well done! That doesn't address my last comment though, any idea regarding this? Is it just unavoidable because this is due to GTK? In the end the peak memory consumption is 30MB so I guess it's not such a big deal.
I would presume that it's Gtk related and sort-of-normal, but you can for starters test and see what the differences are in terms of memory consumption for 0.2.4, which still uses Gtk+2.
Good point. I tried with 0.2.4, and I observe something similar (starts around 11 MB, peak at 15 MB). The peak is lower though, but as you said this might well be just an overhead from GTK3. Also with 0.2.4 calling notify-send in such a tight loop makes all windows freeze for several seconds (and then displays all the notifications at once), whereas with 0.3.0 there is no freeze and things go relatively smoothly, so there's definitely an improvement on this side.