Bug 443401 - 300 processes of drkonqi-coredump-processor occupying 100% of CPU, Plasma desktop unusable.
Summary: 300 processes of drkonqi-coredump-processor occupying 100% of CPU, Plasma des...
Status: RESOLVED WORKSFORME
Alias: None
Product: drkonqi
Classification: Applications
Component: general (other bugs)
Version First Reported In: master
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-06 14:31 UTC by Laura David Hurka
Modified: 2021-10-06 18:18 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
htop showing drkonqi-coredump-processor processes. (627.08 KB, image/png)
2021-10-06 14:31 UTC, Laura David Hurka
Details
htop showing one of 12 drkonqi-coredump-launcher processes and 3 children. (48.88 KB, image/png)
2021-10-06 15:00 UTC, Laura David Hurka
Details
Aptitude log of the update which led to this problem. (85.90 KB, text/plain)
2021-10-06 18:17 UTC, Laura David Hurka
Details
Aptitude log of the actions which did not change this problem. (8.49 KB, text/plain)
2021-10-06 18:18 UTC, Laura David Hurka
Details
Aptitude log of the update which made this problem disappear. (8.98 KB, text/plain)
2021-10-06 18:18 UTC, Laura David Hurka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laura David Hurka 2021-10-06 14:31:02 UTC
Created attachment 142209 [details]
htop showing drkonqi-coredump-processor processes.

SUMMARY
Since the last updates today, I am not able to use my KDE Neon developer edition machine anymore, because many drkonqi-coredump-processor processes make it totally unresponsive after a few seconds.
These processes appear at a rate of 1Hz.

At the same time, I observe a similar amount of sddm-greeter processes appearing, each doing nothing.

When I log out fast enough, I can see one additional sddm-greeter process, which is operational and does the login screen. The drkonqi-coredump-processor processes continue to run, until they disappear after 300 seconds.

STEPS TO REPRODUCE
1. Log in graphically on KDE Neon developer edition, with a local X session

OBSERVED RESULT
Every second a process appears and runs at full CPU load:
`drkonqi-coredump-processor <long constant hex> <integer, counting up>`

EXPECTED RESULT
No such processes appear.
In case sddm-greeter (or something else) actually crashes and causes these processes to appear, they should not lock up at 100% CPU.

SOFTWARE/OS VERSIONS
$ ssh -X david@tarja kinfocenter
Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.23.80
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.3
Kernel Version: 5.11.0-37-generic (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 4800U with Radeon Graphics
Memory: 30.8 GiB of RAM
Graphics Processor: llvmpipe

$ ssh david@tarja apt show drkonqi
Version: 5.22.5+p20.04+tunstable+git20211006.0214-0

$ ssh david@tarja apt show sddm
0.19.0+p20.04+tunstable+git20211004.1953-0
Comment 1 Laura David Hurka 2021-10-06 15:00:14 UTC
Created attachment 142211 [details]
htop showing one of 12 drkonqi-coredump-launcher processes and 3 children.

Downgrading drkonqi to 5.22.5+p20.04+tunstable+git20210917.0137-0 does not change anything.

Downgrading sddm to 0.18.1-1ubuntu2 does not change anything.

I can see 12 inactive processes of drkonqi-coredump-launcher starting at login and quitting at logout. I think this is not related (12 != 300), I cc-ed Frameworks anyway.
Comment 2 Laura David Hurka 2021-10-06 18:17:16 UTC
Created attachment 142219 [details]
Aptitude log of the update which led to this problem.

The issue went away itself after installing more updates. I do not know which package may have caused this, neither drkonqi nor sddm were updated.

In case this becomes relevant again, I am attaching my aptitude logs.
Comment 3 Laura David Hurka 2021-10-06 18:18:01 UTC
Created attachment 142220 [details]
Aptitude log of the actions which did not change this problem.
Comment 4 Laura David Hurka 2021-10-06 18:18:35 UTC
Created attachment 142221 [details]
Aptitude log of the update which made this problem disappear.