! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Potential memory leak when repeatedly reconnecting HDMI cable
Status:
RESOLVED: FIXED
Product:
Xfdesktop
Component:
General

Comments

Description Tiberiu Viuleț 2018-11-05 11:36:40 CET
Repeatedly disconnecting and reconnecting HDMI cable leads to memory usage by xfdesktop, as reported by top (RES and VIRT), to increase continuously. This does not happen when using a DisplayPort cable. 

Issue was replicated with multiple NUC7i3BNK and NUC6i3SYK.

Underlying OS was Ubuntu 18.04.01 with xfce installed by xubuntu-desktop package.
Comment 1 Skunnyk editbugs 2018-11-11 10:49:08 CET
It seems to be related to https://bugzilla.xfce.org/show_bug.cgi?id=12805 , and has been fixed in xfdesktop 4.13.2
Ubuntu 18.10 is using 4.13.2, but the backport has not been done in 18.04 / 4.12 branch. Maybe we need to backport to 4.12 branch.
Comment 2 flocculant 2018-11-11 11:22:29 CET
@Tiberlu - can you report this on Launchpad, ubuntu-bug xfdesktop4 from a terminal will gather information. You can then link this xfce report to the new Launchpad one.

Without a bug report on Launchpad we'd be unable to do the necessary SRU work.
Comment 3 Tiberiu Viuleț 2018-11-12 16:44:14 CET
@flocculant I reported it to Canonical https://bugs.launchpad.net/ubuntu/+source/xfdesktop4/+bug/1802939
Comment 4 Andre Miranda editbugs 2019-05-02 20:12:26 CEST
I thought this bug has been resolved since then, unfortunately it is not the case.
I wasn't able to track down where the leak comes from but this is what I could gather so far:

- every time laptop's lid is closed and opened xfdesktop leaks about 20 MiB.
- using a solid color instead of image as backdrop does not help, xfdesktop seems to load an image (xfce-teal.jpg) all the same.
- valgrind tells there is a huge leak from memory allocated at xfce_backdrop_file_input_stream_ready_cb (xfce-backdrop.c:2031).
- commenting out the content of xfce_backdrop_generate_async after its last conditional return stops the leak, so valgrind seems to be right, however nothing will be drawn. If solid color is used all is good.
- commenting out screen_size_changed_cb from xfce_desktop_monitors_changed fixes the problem when the lid is reopen, but when an external monitor is plugged the backdrop is not drawn.
Comment 5 alexxcons editbugs 2019-05-13 10:43:14 CEST
Created attachment 8517 
removed recursion, sync load. Still leaking

To simplify debugging, I removed the recursion aspect by synchroniously loading the input stream .... though it just simplyfied the problem. The leak on lid close is still present.

Currently getting a crit after the method got called .. possibly related:
(xfdesktop:15978): GLib-GObject-CRITICAL **: 10:36:50.212: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

will further debug if I have time
Comment 6 Git Bot editbugs 2019-05-17 18:59:47 CEST
Andre Miranda referenced this bugreport in commit 9b2dc2f71f360290e1b0d15cb68d3dd5f91d2bbb

Fix memory leak when monitors change (Bug#14844)

https://git.xfce.org/xfce/xfdesktop/commit?id=9b2dc2f71f360290e1b0d15cb68d3dd5f91d2bbb
Comment 7 Andre Miranda editbugs 2019-05-17 19:06:17 CEST
So, the problem never was "xfce_backdrop_generate_async" otherwise cycling wallpapers every second would leak (which was not the case). The problem comes from the wallpaper cache that is not used when monitors change, because "xfce_workspace_monitors_changed" destroy all instances of XfceBackdrop just to create them again.

The real problem is that "xfce_workspace_remove_backdrops" never removed all backdrops, it was limited by the number of monitors: when the external monitor is unplugged we obviously are left with just 1 but there are 2 backdrops in the array!

Please let me know if the fix works for you guys before closing this bug.
Comment 8 alexxcons editbugs 2019-05-17 22:39:58 CEST
Hmm ... now it is at least different :P   Seems like lid open/close still leaks sometimes, but not as reliable as before.
Possibly a differnt bug. Each line is one lid close/open:

Second value is %MEM

schwinn@schwinn-laptop2:~/git/xfdesktop$ ps -aux | grep src/xfdesktop
schwinn  13159 18.4  1.3 438632 51648 pts/1    Sl+  22:32   0:00 ./src/xfdesktop
schwinn  13159 13.2  3.2 568740 120888 pts/1   Sl+  22:32   0:01 ./src/xfdesktop
schwinn  13159 11.1  3.7 586740 138888 pts/1   Sl+  22:32   0:02 ./src/xfdesktop
schwinn  13159 10.1  3.7 586740 138888 pts/1   Sl+  22:32   0:02 ./src/xfdesktop
schwinn  13159 10.2  3.2 568740 121016 pts/1   Sl+  22:32   0:03 ./src/xfdesktop
schwinn  13159 10.3  3.2 568740 121016 pts/1   Sl+  22:32   0:03 ./src/xfdesktop
schwinn  13159  8.8  3.2 568740 121016 pts/1   Sl+  22:32   0:03 ./src/xfdesktop
schwinn  13159  9.1  3.2 568740 121016 pts/1   Sl+  22:32   0:04 ./src/xfdesktop
schwinn  13159  8.6  3.7 586740 139016 pts/1   Sl+  22:32   0:05 ./src/xfdesktop
schwinn  13159  8.8  3.7 586740 139016 pts/1   Sl+  22:32   0:05 ./src/xfdesktop
schwinn  13159  8.8  5.1 638940 191088 pts/1   Sl+  22:32   0:06 ./src/xfdesktop
schwinn  13159  8.9  5.1 638940 191088 pts/1   Sl+  22:32   0:06 ./src/xfdesktop
schwinn  13159  9.0  5.6 656940 209088 pts/1   Sl+  22:32   0:07 ./src/xfdesktop
schwinn  13159  8.9  5.6 656940 209088 pts/1   Sl+  22:32   0:08 ./src/xfdesktop
schwinn  13159  8.5  5.6 656940 209088 pts/1   Sl+  22:32   0:08 ./src/xfdesktop

Hope my laptop is not going to break for this bug :P
Comment 9 Andre Miranda editbugs 2019-05-18 22:32:03 CEST
For me it leaks just once, i.e. xfdesktop starts at 40MiB then jumps to 61MiB after the lid is reopened the first time, but then it stops leaking. Judging from the code, there is a lot of room for improvements, I guess this leak is actually the pixbuf cache which consumes a lot of memory (imagine the bitmap size of a 4K wallpaper) just for workspace switches to be faster (I remember there is a bug complaining about flickering when switching workspace, so...).
Comment 10 Andre Miranda editbugs 2019-06-27 16:27:38 CEST
I'm closing this bug, if any of you still get leaks, please reopen or file a new one.

Bug #14844

Reported by:
Tiberiu Viuleț
Reported on: 2018-11-05
Last modified on: 2019-06-27

People

Assignee:
Eric Koegel
CC List:
4 users

Version

Version:
4.12.4

Attachments

Additional information