Created attachment 141827 [details] plasmashell memory leaks after receive notifications SUMMARY plasmashell memory leaks after receive notifications STEPS TO REPRODUCE 1. Send notifications with `notify-send` via konsole `while true; do notify-send "Test: $(date)"; sleep 1; done` 2. Need to kill and restart plasmashell to get it back to normal memory usage OBSERVED RESULT plasmashell memory increases and never decrease after receive notifications EXPECTED RESULT plasmashell memory could decrease back to normal after notifications disapear SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch Linux (available in About System) KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86 Qt Version: 5.15.2 ADDITIONAL INFORMATION I use Intel discrete graphic and disabled Nvidia graphic with bumblebee ❯ inxi -CG CPU: Info: Dual Core model: Intel Core i3-2370M bits: 64 type: MT MCP cache: L2: 3 MiB Speed: 2306 MHz min/max: 800/2400 MHz Core speeds (MHz): 1: 2306 2: 1534 3: 1707 4: 1529 Graphics: Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics driver: i915 v: kernel Device-2: NVIDIA GF119M [GeForce 610M] driver: N/A Display: wayland server: X.Org 1.21.1.2 driver: loaded: intel resolution: 1366x768~60Hz OpenGL: renderer: Mesa DRI Intel HD Graphics 3000 (SNB GT2) v: 3.3 Mesa 21.2.2
I can reproduce this issue with that command, also with an Intel iGPU (HD 620). Memory use steadily increases over time and doesn't go down. There is probably a small memory leak in every notification somewhere.
@Nate can you see if removing the spinning indicator "fixes" it?
Will do!
Nope, memory still leaks even with the Chart component (and its import in the file) removed.
I can also reproduce it on amdgpu. Operating System: openSUSE Tumbleweed 20210920 KDE Plasma Version: 5.23.80 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Kernel Version: 5.14.5-1-default (64-bit) Graphics Platform: X11 Processors: 8 × AMD Ryzen 7 4700U with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor: AMD RENOIR
Perhaps the culprit is in the notification panel?
can confirm it on amdgpu as well Operating System: openSUSE Tumbleweed 20210922 KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Kernel Version: 5.14.5-1-default (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 5700
>Perhaps the culprit is in the notification panel? What specifically?
*** Bug 442848 has been marked as a duplicate of this bug. ***
Can you reproduce memory leak with `while true; do kdialog --passivepopup "$(date)" 5;sleep 1;done` I can't see obvious memory leak with `kdialog`.
kdialog has a default timeout for 10s, and -1 for notify-send. I added `-t 5` to notify-send, and also didn't see memory leak.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1115
> Can you reproduce memory leak with > > `while true; do kdialog --passivepopup "$(date)" 5;sleep 1;done` > > I can't see obvious memory leak with `kdialog`. Memory leaks still occur.
(In reply to Wachid Adi Nugroho from comment #13) > > Can you reproduce memory leak with > > > > `while true; do kdialog --passivepopup "$(date)" 5;sleep 1;done` > > > > I can't see obvious memory leak with `kdialog`. > Memory leaks still occur. Does it get faster or slower to leak?
In libnotificationmanager/abstractnotificationsmodel.cpp: "notificationTimeouts" hash list become larger and larger as there are only insert actions but no remove actions.
Does memory usage goes stable after 3 minutes even if the loop is still running?
(In reply to qydwhotmail from comment #16) > Does memory usage goes stable after 3 minutes even if the loop is still > running? No, memory leaks still occur after 3 minutes.
(In reply to qydwhotmail from comment #14) > (In reply to Wachid Adi Nugroho from comment #13) > > > Can you reproduce memory leak with > > > > > > `while true; do kdialog --passivepopup "$(date)" 5;sleep 1;done` > > > > > > I can't see obvious memory leak with `kdialog`. > > Memory leaks still occur. > > Does it get faster or slower to leak? Start with plasma memory usage about 125-130 MB, monitored with ksysguard * 5 minutes run - kdialog = 1.487.444 K - notify-send = 1.676.308 K * Reach 1 GB in - kdialog = 3m 9s - notify-send = 2m 42s Slower memory leaks with kdialog
(In reply to Wachid Adi Nugroho from comment #17) > (In reply to qydwhotmail from comment #16) > > Does memory usage goes stable after 3 minutes even if the loop is still > > running? > > No, memory leaks still occur after 3 minutes. I can't reproduce this bug anymore, add back Intel GPU to the title.
Looks like this has been traced to an issue in a Qt patch collection backport: https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/2#note_352996
Created attachment 144331 [details] heaptrack summary I'm not using wayland and have had this issue for months I'd say. I only just now opted to "heaptrack" it over the past day. (attached screenshot of summary) It's currently consumed ~640MB (uptime ~12 days). I'm not sure how to interpret the output as it looks like the "perceived" leaks seem low. Maybe it just doesn't consider other stuff no longer used/meaningful as still not having yet leaked. I've got a very old Haswell (hurry up and give us an I3 Alder Lake Intel, I'm ready).
(In reply to vindicator from comment #21) > Created attachment 144331 [details] > heaptrack summary > > I'm not using wayland and have had this issue for months I'd say. > I only just now opted to "heaptrack" it over the past day. (attached > screenshot of summary) > It's currently consumed ~640MB (uptime ~12 days). > I'm not sure how to interpret the output as it looks like the "perceived" > leaks seem low. > Maybe it just doesn't consider other stuff no longer used/meaningful as > still not having yet leaked. > I've got a very old Haswell (hurry up and give us an I3 Alder Lake Intel, > I'm ready). Are you using Activities? It could be another issue. https://bugs.kde.org/show_bug.cgi?id=422755
While I do have a few Activities set, I haven't used them in at least a couple of years. Something to take a look at is the memory usage when you do something like "Clear History" for notifications or clipboard. When I cleared my clipboard, plasmashell went from 307MB to 314MB (I had used --replace when plasmashell was >600MB).
*** Bug 412865 has been marked as a duplicate of this bug. ***
Created attachment 144354 [details] Heaptrack plasmashell with i965 and crocus drivers I used `ksysguard` and `heaptrack` to monitor memory usage of `plasmashell` for 5 minutes running with two different drivers `i965_dri.so` and `crocus_dri.so`. Procedure: - Open `ksysguard` - End Process of `plasmashell` - Open `konsole` with Ctrl+Alt+T shortcut, then Spit View or New Tab - Test with default driver (`i965_dri.so`) * `heaptrack /usr/bin/plasmashell` * `while true; do notify-send "Test plasmashell memory leaks: $(date)"; sleep 1; done` * Stop them Ctrl+C after 5 minutes - Test with Crocus driver (`crocus_dri.so`) * `MESA_LOADER_DRIVER_OVERRIDE=crocus heaptrack /usr/bin/plasmashell` * `export MESA_LOADER_DRIVER_OVERRIDE=crocus; while true; do notify-send "Test plasmashell memory leaks: $(date)"; sleep 1; done` * Stop them Ctrl+C after 5 minutes Monitoring results at `ksysguard` (KDE System Monitor) | Driver | Begin | End | |--------|---------|----------| | i965 | 130 MiB | 1145 MiB | | crocus | 95 MiB | 360 MiB | Heaptrack files https://drive.google.com/drive/folders/11Z9d0miByLll-XrxcS3Riow3_QY3YOcO Using the Crocus driver can significantly reduce memory leaks, but memory leaks still occur. So I think there needs to be a fix from the GPU drivers and KDE Plasma side.
Created attachment 144365 [details] PoC qtwayland context leak patch (In reply to Wachid Adi Nugroho from comment #25) > Created attachment 144354 [details] > Heaptrack plasmashell with i965 and crocus drivers [...] > Using the Crocus driver can significantly reduce memory leaks, but memory > leaks still occur. According to your heaptrack files it looks like you're using Wayland, so it's likely to be (at least partially) the leak mentioned in comment 20. If you're okay with building patched QtWayland, you can try the attached patch.
A possibly relevant merge request was started @ https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/25
(In reply to Denis Lisov from comment #26) > Created attachment 144365 [details] > PoC qtwayland context leak patch > > (In reply to Wachid Adi Nugroho from comment #25) > > Created attachment 144354 [details] > > Heaptrack plasmashell with i965 and crocus drivers > [...] > > Using the Crocus driver can significantly reduce memory leaks, but memory > > leaks still occur. > > According to your heaptrack files it looks like you're using Wayland, so > it's likely to be (at least partially) the leak mentioned in comment 20. If > you're okay with building patched QtWayland, you can try the attached patch. Trying to build qtwayland with your patch, the results significantly reduce memory leaks :) but it looks like there are still a few memory leaks | time | i965 | crocus | |:-----:|:-------:|:-------:| | 1'00" | 301 MiB | 220 MiB | | 1'30" | 304 MiB | 225 MiB | | 2'00" | 307 MiB | 223 MiB | | 2'30" | 321 MiB | 224 MiB | | 3'00" | 331 MiB | 224 MiB | | 3'30" | 333 MiB | 232 MiB | | 4'00" | 335 MiB | 236 MiB | | 4'30" | 337 MiB | 237 MiB | | 5'00" | 336 MiB | 237 MiB | Heaptrack files https://drive.google.com/drive/folders/11Z9d0miByLll-XrxcS3Riow3_QY3YOcO
Git commit eb422ab5e07498a7a8d086f6a942ee35ab3c9776 by Aleix Pol. Committed on 09/12/2021 at 16:38. Pushed by aacid into branch 'kde/5.15'. Fix backport, context destruction was omitted When cherry-picking for 9df11e79b46c77d8c83f765b2a8e85b639fd55a2, this line got removed when rebasing the patch, which created a leak. Change-Id: Id00e8b194dcd910c5f01ce9d2cc318f96a4129a2 M +1 -0 src/hardwareintegration/client/wayland-egl/qwaylandglcontext.cpp https://invent.kde.org/qt/qt/qtwayland/commit/eb422ab5e07498a7a8d086f6a942ee35ab3c9776