Bug 418442 - Experiencing 100% cpu usage whenever a notification is present
Summary: Experiencing 100% cpu usage whenever a notification is present
Status: RESOLVED DUPLICATE of bug 423594
Alias: None
Product: plasmashell
Classification: Plasma
Component: Notifications (show other bugs)
Version: 5.18.1
Platform: Arch Linux Linux
: NOR normal
Target Milestone: 1.0
Assignee: Kai Uwe Broulik
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-03 19:48 UTC by jeep70cp
Modified: 2020-09-10 02:46 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jeep70cp 2020-03-03 19:48:12 UTC
SUMMARY
When there is a notification present on plasma >=5.18.0, plasmashell uses 100% cpu usage.


STEPS TO REPRODUCE
1. Receive a notification, for example through plasma-nm or the notify-send command
2. check htop or ksysguard and observe 100% CPU usage from plasmashell

OBSERVED RESULT
100% CPU usage whenever a notification is present, in addition notifications taking ages to disappear.

EXPECTED RESULT
Notifications behaving as expected, not causing 100% cpu usage, and disappearing in a matter of seconds rather than minutes.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.57
(available in About System)
KDE Plasma Version: >=5.18.0
KDE Frameworks Version: 5.67
Qt Version: 5.14.1

ADDITIONAL INFORMATION
Still presents with compositor disabled. Still presents also with notification widget disabled. I am using a Thinkpad T60 with ATI X1300 graphics and a T7200 CPU.
Comment 1 Kai Uwe Broulik 2020-03-06 07:40:46 UTC
Can you get a backtrace or perf file for when that happens?
Comment 2 jeep70cp 2020-03-07 22:07:21 UTC
Here is a perf file: http://s000.tinyupload.com/index.php?file_id=74021570478791780318

I am new to this, so I am not sure I did it right, but what I used was:
perf record -F 99 plasmashell

I am not sure how to get a backtrace.
Comment 3 jeep70cp 2020-04-22 21:05:44 UTC
Still experiencing this with 5.18.4. It can be mitigated by turning animation speed to instant.
Comment 4 jeep70cp 2020-06-25 22:31:21 UTC
Seems fixed in 5.19!
Comment 5 jeep70cp 2020-06-25 22:40:55 UTC
I actually had xfce4-notifyd running and I didn't notice. It doesn't stay pinned at 100% anymore though--just maxes out the cpu for about three seconds.
Comment 6 jeep70cp 2020-06-25 22:43:01 UTC
I will note that the notification timeout throbber does not appear the entire time, and when it stops lagging the close button becomes a black square. I would bet that the lag is related to some issue with that indicator.
Comment 7 jeep70cp 2020-06-25 22:45:49 UTC
I've got an error when running from the console:

r300 FP: Compiler Error:
../mesa-20.1.2/src/gallium/drivers/r300/compiler/r500_fragprog_emit.c::emit_paired(): emit_alu: Too many instructions
Using a dummy shader instead.

It appears when the close button turns to a black square and the 100% cpu stops.
Comment 8 Nate Graham 2020-09-09 03:46:08 UTC
I can confirm this on my machine. Receiving a notification of any kind briefly spikes the CPU waaaaay high. When you get a bunch of notifications all at once, it can freeze the whole system as various people are reporting in Bug 423594.

*** This bug has been marked as a duplicate of bug 423594 ***
Comment 9 Bruno Cornec 2020-09-10 00:48:41 UTC
It's so regular that I've written this small script to restart it. If it can be useful meanwhile (needs top):

#!/usr/bin/perl -w

use strict;

open(PIPE,"top -b -d 60 |") || die "Unable to execute top";
while (<PIPE>) {
        $_ =~ s/^ *//;
        my @fields = split(/ +/,$_);
        if ((defined $fields[13]) && ($fields[13] =~ /^\/bin\/plasmashell/)) {
                # Does it use 100% ?
                $fields[8] =~ s/,/./;
                #print "CPU% : $fields[8]\n";
                if ($fields[8] >= 100) {
                        print "Restarting plasmashell - ";
                        system("date");
                        system("pkill plasmashell");
                        system("/bin/plasmashell &");
                }
        }
}
Comment 10 Nate Graham 2020-09-10 02:46:22 UTC
omg