SUMMARY I have a standard KDE installation under Arch, I've noticed that when I receive a lot of notifications, for example from KDE connect when someone starts sending me dozens of images, the cpu of my laptop (Lenovo X1 Carbon) goes up to 100% and everything starts lagging. Then plasmadesktop's memory increases and sometimes it uses 900mb and I have to kill and restart it. STEPS TO REPRODUCE 1. Connect KDE connect (I use Android, but it shouldn't matter) 2. Ask someone to send you a lot of messages all together (usually photos) 3. See plasmadesktop memory/cpu increase OBSERVED RESULT It's painful :) EXPECTED RESULT It shouldn't lag so much when many notifications are received, may it should delay the notification to group them, or notify only one of them. And most important it should have memory leaks SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch 5.19.2 KDE Plasma Version: 5.19.2 KDE Frameworks Version: 5.71 Qt Version: 5.15
I've had this happen as well. Here's how I can reproduce it: 1. Open Telegram 2. Put the computer to sleep 3. Receive hundreds of messages in Telegram 4. Wake up and unlock the computer Plasmashell will then receive a flood of notifications from Telegram that spikes the CPU and memory usage, and can even render the shell frozen for a period of time.
*** Bug 422370 has been marked as a duplicate of this bug. ***
*** Bug 398117 has been marked as a duplicate of this bug. ***
*** Bug 418205 has been marked as a duplicate of this bug. ***
*** Bug 418442 has been marked as a duplicate of this bug. ***
I can confirm this issue on my machine.
I can also reproduce this when a large number of notifications get *deleted*. Consider the following: 1. Open Telegram and connect to a high-volume room (e.g. the KDE VDG room) 2. Focus a different room 3. Put the computer to sleep 4. Wake the computer up 12 hours or a day or two later Telegram will now send hundreds of notifications, one for each unread message. This is annoying and can *sometimes* freeze the system. HOWEVER! If you then make the mistake of clicking on the room that sent the messages, Telegram will revoke all of the notifications at once (because they're no longer considered unread, presumably) , which will prompt the notifications on screen to go ballistic! They will all try to disappear at once, and will overlap one another and freeze the system 100% of the time (in my experience)
Version: 5.19.5-3 I've just experienced this myself for the (first? Maybe never before or for years.) time. Except I only see 2 frozen notifications. I attached the the plasmashell process and got a backtrace for it: ***** #0 0x00007f28ee0436a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x00007f28eeb880d4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt5Core.so.5 #2 0x00007f28f080f5d7 in () at /usr/lib/libQt5Quick.so.5 #3 0x00007f28f0878bb7 in QQuickWindow::event(QEvent*) () at /usr/lib/libQt5Quick.so.5 #4 0x00007f28ef883752 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #5 0x00007f28eed67cda in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5 #6 0x00007f28ef12f319 in QPlatformWindow::windowEvent(QEvent*) () at /usr/lib/libQt5Gui.so.5 #7 0x00007f28ef88a437 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #8 0x00007f28eed67cda in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5 #9 0x00007f28eedbfcc5 in QTimerInfoList::activateTimers() () at /usr/lib/libQt5Core.so.5 #10 0x00007f28eedc05aa in () at /usr/lib/libQt5Core.so.5 #11 0x00007f28ed1e2bfc in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #12 0x00007f28ed2341f9 in () at /usr/lib/libglib-2.0.so.0 #13 0x00007f28ed1e1421 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #14 0x00007f28eedc0941 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #15 0x00007f28eed6665c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #16 0x00007f28eed6eaf4 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5 #17 0x00005e570ab3bf5d in () #18 0x00007f28ee734152 in __libc_start_main () at /usr/lib/libc.so.6 #19 0x00005e570ab3c19e in _start () ***** In the meantime, I'll just --replace it.
... or maybe I won't --replace it (because it just doesn't want to), and I have to SIGTERM it.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/495
Git commit d8e0071f1d735238feee5b181c30ab45cbc54803 by Kai Uwe Broulik. Committed on 11/01/2021 at 19:06. Pushed by broulik into branch 'master'. [Notifications] Compress removal of notifications When removing a notification, it is removed from the model, which will cause the view to update and move up an older notification, if any. If you now delete a bunch of notifications in quick succession we will create a dialog every time which then gets deleted again, causing another notification to move up, etc causing high CPU spikes and plasma freezes. This patch compresses removing notifications and tries to announce consecuetive ranges of notifications to be removed in one go. FIXED-IN: 5.21.0 M +71 -38 libnotificationmanager/abstractnotificationsmodel.cpp M +2 -0 libnotificationmanager/abstractnotificationsmodel.h M +8 -0 libnotificationmanager/abstractnotificationsmodel_p.h M +66 -1 libnotificationmanager/autotests/notifications_test.cpp M +1 -1 libnotificationmanager/notificationsmodel.h https://invent.kde.org/plasma/plasma-workspace/commit/d8e0071f1d735238feee5b181c30ab45cbc54803
Remove subscriber per abuse report
*** Bug 433775 has been marked as a duplicate of this bug. ***
*** Bug 435506 has been marked as a duplicate of this bug. ***