SUMMARY Hi, This is a weird bug, but from all my testing ( more than a week trying to find out what was happening ), its a bug that only happens on kwin wayland ( not on x11 ). So, I have to use an javafx proprietary app, that when using with kwin wayland, works completly fine, until .... screensaver activates and turns off the monitors. By screensaver, I mean just the power idle setting to turn the monitors off, not any fancy screensaver effect. What happens is that the app is running fine, usually using about 1GB/2GB of ram ( I have 16GB, so lots of free ram ). As soon as the screensaver activates ( this can be a 1 minute idle timeout or 1 hour, doesn't matter ), in seconds, all ram is filled and oom daemon either starts killing or ( if oom daemon disabled ) the computer gets unresponsive. It fills around 13/14 GB of ram and 4 GB of swap space in seconds. I am writting this bug report on kwin wayland, because this doesn't happen on kwin X11. It also doesn't happen on gnome wayland. It also doesn't happen on sway. Also this only happens when javafx is using es2 gpu acceleration ( doesn't happen on software mode, but software mode is almost unusable, the app is very graphic intensive ). I have tested also with kde stable releases on gentoo and arch, and kde master git on opensuse. I also tried the latest jdk different GC's and with different heap memory settings. I understand that this is not much info or that its hard to say that is not a bug elsewhere. But the bug is reproducible. Unfortunatly, its a proprietary app. I will try to find an open source javafx app to make it easier to be reproducible by others. Please let me know what further steps I can take to track this issue and provide better info. STEPS TO REPRODUCE 1. start app 2. dont touch computer to let screensaver kick in 3. watch in another computer through ssh memory get completly filled seconds after monitors turn off OBSERVED RESULT Memory starts getting completly filled and all swap is used. OOM either kicks in and kills apps or computer gets unresponsive. EXPECTED RESULT Like what happens on kwin x11, gnome wayland or sway... memory keeps about the same after screensaver as before. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Can you please provide an example program that suffers from this problem? As is, this bug report is somewhat inactioable due to the lack of information. Also, it will be helpful to have WAYLAND_DEBUG log of the app when the screen is off.
(In reply to Vlad Zahorodnii from comment #1) > Can you please provide an example program that suffers from this problem? As > is, this bug report is somewhat inactioable due to the lack of information. > Also, it will be helpful to have WAYLAND_DEBUG log of the app when the > screen is off. Sorry, I understand that its not enough info. I tried WAYLAND_DEBUG, but since its a Xwayland app, it doesn't show anything. If you have suggestion for more info, or any question whatsoever, please feel let me know. I will keep searching for apps that trigger this, as it must be javafx with es2 engine and a lot of graphic work, so its not easy. Thank you.
I have done more testing and found out that it is also triggered with the screensaver ( not only the power devil dpms turning off monitors ). So, with screensaver ( but not turning monitors off ) will also make this happen. I have been using kde/x11 and gnome/wayland all week to confirm that it doesn't happen there, and it doesn't. Attaching screenshot of running htop and wayland_debug output connected through ssh to the computer running the app and in idle mode. Attaching the tar.gz of the full session WAYLAND_DEBUG=1 output.
Created attachment 140575 [details] screenshot of connected to the computer in idle through ssh
Created attachment 140576 [details] full session log of WAYLAND_DEBUG=1 output
well ... some good news: on wayland session, I can't seem to replicate the problem with KWIN_COMPOSE=Q environment variable. although ... not really great performance this way.
hum... I think I found a solution. Gonna test it through all day tomorrow and see if it ever fails. If it doesn't, then I am sure I found a solution and post it here!
Ok, so I tested this bug all day yesterday and I found the following: Using kwin rule, or breeze window decoration rule ( both work ) to hide the window titlebar/borders, and the bug doesn't happen. As long as windows don't have a titlebar, the bug doesn't happen. Next I tried replacing the breeze window decoration with another one, like oxygen, to test, and it triggered immediatly after screensaver. ( so the issue isn't particular to breeze ) This was tested in kde git in gentoo/opensuse and kde latest stable ( 5.22.4 ) in manjaro. I actually found this by accident, because I went back to X11 (where the bug also doesn't happen) and in X11 I like to have no titlebars for windows ( the breeze exception rules for class work on X11, but not on Wayland ). I know this seems very weird, but the bug is reproducible and easy to test. And I tested it alot of times to be sure.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
is it ok to change this to "reported" ? I did gave more info. sorry if its not meant to be me to change it.
Yes, it's fine. If you disable decoration shadows (in breeze deco settings), does memory usage increase?
(In reply to Vlad Zahorodnii from comment #11) > Yes, it's fine. If you disable decoration shadows (in breeze deco settings), > does memory usage increase? I haven't tried that, but I will later today and report back!
(In reply to Alexandre Pereira from comment #12) > (In reply to Vlad Zahorodnii from comment #11) > > Yes, it's fine. If you disable decoration shadows (in breeze deco settings), > > does memory usage increase? > > I haven't tried that, but I will later today and report back! So I tested this with the screensaver (meta+l keyboard shortcut). It is enough to trigger. With showing titlebar in kwinrules, but no shadows on breeze deco: it trigger the issue. It was confirmed by huge memory usage increase ( the mouse started lagging also ). With no titlebar in kwinrules, issue doesn't happen. this on kwin compiled on 28 set
Any client side memory leak is mostly a problem in the client. Can you file a bug report to JavaFX and link here? Attaching the wayland_debug log above. Ideally it might be worth getting a log with "heaptrack"
(In reply to David Edmundson from comment #14) > Any client side memory leak is mostly a problem in the client. > Can you file a bug report to JavaFX and link here? Attaching the > wayland_debug log above. > > Ideally it might be worth getting a log with "heaptrack" It only happens with kwin wayland with window titlebars. Window Titlebars hidden, and it doesn't happen. And I have been using the app every day since late September with this workaround without issues (which is fine by me, because I would use it with hidden titlebars even if no bug) Anyway, from what I have read and talked, JavaFX is working on native wayland. I also can't reproduce with open source JavaFX apps (at least the simple ones I have tried), and the app I use is comercial one. That is why I haven't open a bug on JavaFX side or gave an example here with an open source app.
A similar issue appeared with the same application, and reported bug here: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1664 The issue was very tested and the fix was merged, being that the application is working properly, either with or without the workarounds in this report. Things are working properly now.