Created attachment 118922 [details] plasmashell 5.15.1 gdb bt SUMMARY Chrome and plasmashell freezes/hangs after some time of normal usage. STEPS TO REPRODUCE 1. Run Google Chrome and any other programs. 2. Go about normal usage. OBSERVED RESULT Eventually Chrome and plasmashell become unresponsive. EXPECTED RESULT It should not hang/freeze? If it's a memory issue, handle it. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch Linux (available in About System) KDE Plasma Version: 5.15.3 KDE Frameworks Version: 5.56.0 Qt Version: 5.12.1 ADDITIONAL INFORMATION After some time (days/weeks) of my normal usage, I have been finding more often that Chrome will stop responding (freeze/hang) and so too with plasmashell. Other programs will remain up and usable somehow, and windows can be moved around (including maximize). I think ALT-TAB window-switching also works. It happened for over 1 month and I saw there was an update for plasma* and chrome and decided to upgrade both before submitting the issue. The gdb attachment is from the previous version (5.15.1 & 72.0) of both. Since I see it is happening again, I CAN start a new gdb attachment to this version of plasmashell if so desired.
Actually, the attachment is ONLY of the previous version of plasmashell, NOT chrome. From what I could tell, trying to debug chrome is problematic. If it's needed, so too will be guidance for doing so.
So chrome plays no role in the freezing based on the current freeze. Plasmashell is still frozen and I'm currently still in chrome. I SHIFT-ESC to open System Monitor and added the X11 Memory column after seeing a reference to X11 leaking elsewhere online. Plasmashell currently (in it's frozen state) is consuming 3,357,702K. I have an 8GB system. 3.4GB for pixmaps alone. xrestop is showing "Pixmaps: 180143985087037 total" I did see https://bugs.kde.org/show_bug.cgi?id=319891 and https://www.linuxquestions.org/questions/programming-9/memory-leaks-in-gtk3-code-4175464336/#post4966627 which makes me wonder if my attempt at using valgrind will be useless.
valgrind .... plasmashell --replace didn't do anything. kquitapp5 plasmashell timed out with "Quitting application plasmashell failed. Error reported was:\n\n org.freedesktop.DBus.Error.NoReply : Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." I've seen that before. kill -9 ... for plasmashell kills it and I'm now running plasmashell under valgrind. With plasmashell running fresh now, System Monitor is only showing 16,784K used under "X11 Memory", and xrestop is showing "Pixmaps: 75090K total"
In the amount of time since my last comment, I've opened the android emulator, and vlc. Nothing notable regarding pixmaps came from the emulator and vlc wasn't bad either, but the pixmaps jumped when I hovered over the vlc application in the bottom open-application panel, giving the application preview. Now in like less than 1 hour having elapsed, plasmashell overtook KWin in xrestop and is standing at 79791K. In addition, valgrind gave me a laugh by reprimanding the plasmashell devs with: "More than 10000000 total errors detected. I'm not reporting any more. Final error counts will be inaccurate. Go fix your program!..." The log file is at 774KB. I've done that "hovering" a bunch of different times for different programs and they all cause the pixmaps to increase and never seems to release any of the memory.
Because the pixmaps had climbed to 200MB in less than 1 day, I thought I'd try something else... "Configure Task Manager" "Show tooltips": Uncheck "Highlight windows": Uncheck "Show progress bar and status information in task buttons": Uncheck "Mark applications that play audio": Uncheck My main thought was really all about the "tooltips" part. I ran "plasmashell --replace", and with 25 hours having elapsed, the pixmaps had only increased to 22MB (from 16.7MB), compared to the over 200MB in less than 1 day. Can someone at least provide thoughts on this observation? I'm going to edit the title of this bug from "Plasmashell And Google Chrome Freeze", since it now appears to be all about pixmaps and plasmashell.
The last Qt graphic leak was indirectly caused by the tooltip. The tooltip created a new window, which gets hidden. A hidden window meant it never rendered, because a window was marked as not being rendered yet texture deletion was deferred. Qt: 839f09c65523fb5c419b62e078f72bb39285449a But I fixed that in Qt5.11 - unless someones broken it again.
qt5-base 5.12.2-2 xorg-server 1.20.4-1 plasma-workspace 5.15.4-1 I have the same problem on Arch Linux with the above packages, and I think it also happens with Qt 5.12.x (before 5.12.2). Sometimes X eats several GBs of memory, and xrestop shows that plasmashell is the culprit. Currently, Xorg resident memory usage is 966MB and xrestop shows: res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 2600000 20 11 1 70 223 626727K 6K 626734K 3625 Desktop ~@~T Plasma A restart of plasmashell is sufficient to let X free the memory.
I have the same issue on Arch linux. There is very good chance that this leak is related to intel graphics driver: # pmap -x -p $(pidof Xorg) | head -20 1306: /usr/lib/Xorg -nolisten tcp -auth /var/run/sddm/{377320b3-66db-45c6-aac2-fce784945c1f} -background none -noreset -displayfd 17 -seat seat0 vt1 Address Kbytes RSS Dirty Mode Mapping 000055664b7ee000 180 0 0 r---- /usr/lib/Xorg 000055664b81b000 1576 1124 0 r-x-- /usr/lib/Xorg 000055664b9a5000 444 156 0 r---- /usr/lib/Xorg 000055664ba14000 16 16 16 r---- /usr/lib/Xorg 000055664ba18000 24 24 24 rw--- /usr/lib/Xorg 000055664ba1e000 128 60 60 rw--- [ anon ] 000055664ca36000 76316 75992 75992 rw--- [ anon ] 00007f64253f2000 8100 8100 8100 rw-s- /i915 (deleted) 00007f6426d7d000 6664 6664 6664 rw-s- /i915 (deleted) 00007f64273ff000 8100 8100 8100 rw-s- /i915 (deleted) 00007f6427be8000 7680 7680 7680 rw-s- /i915 (deleted) 00007f6428368000 7920 7740 7740 rw-s- /i915 (deleted) 00007f6428b24000 7680 7680 7680 rw-s- /tmp/#31647510 (deleted) 00007f64292a4000 7680 7680 7680 rw-s- /i915 (deleted) 00007f6429a24000 8192 8192 0 rw-s- /i915 (deleted) 00007f642a224000 7680 7680 2020 rw-s- /i915 (deleted) 00007f642a9a4000 8100 8100 8100 rw-s- /tmp/#31166531 (deleted) 00007f642b18d000 7680 7680 2904 rw-s- /i915 (deleted) # pmap -x -p $(pidof Xorg)|awk '/i915/{sum+=$3} END{print sum}' 836616 # ps -o rss -C Xorg RSS 1012412 Also in discussion at https://bbs.archlinux.org/viewtopic.php?id=245550 all people with this issue have intel graphics and everyone with another GPU do not have it. On another hand on my system it appeared about the same time plasma was upgraded to 5.15, so changes in plasma likely to be involved.
Created attachment 119959 [details] Graph of memory leak
After update to 5.16.0 (or probably 5.16.1) I don't observe this leak anymore.
Same. Marking it as fixed. I'm on 5.16.2 as of a few days ago and xrestop shows it's behaving. I upgraded at that time because of 2 issues which I didn't post about... 1) I had previously disabled the window thumbnails because of that "leak" and switched to the window previews, which had it's own problems such as it not handling the mouse movements in time when under load and keep the transparency in place until I hovered over a window in the application panel again. Other times, if I right mouse on a window in the panel to get the context menu options, again it would sometimes switch to transparency because of load/timing and I couldn't even see the menu. Great features, buggy implementations. Nice to get this back though. 2) Some new bizarre encounter where plasmashell and ksysguardd were pulsing high cpu usage. I upgraded on the day after that began. Another reason to upgrade was a supposed fix to another "feature" (not really a bug) I posted about, regarding a change with the notification system where I began to get bursts of notifications. I'll have to look again because I thought it was this release, but it's still happening. Whatever the case, this issue seems to be resolved by "something".