Bug 276825

Summary: plasma-desktop sucks all available resources then crashes on shutdown
Product: [Unmaintained] plasma4 Reporter: Carl Schmidtmann <kde>
Component: generalAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED UNMAINTAINED    
Severity: crash CC: gregor
Priority: NOR    
Version: 4.6.3   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Yesterday's backtrace and ps list from today

Description Carl Schmidtmann 2011-06-30 14:08:53 UTC
Created attachment 61482 [details]
Yesterday's backtrace and ps list from today

Version:           unspecified (using KDE 4.6.3) 
OS:                Linux

In the morning after system left on over night plasma-desktop is using 97% of the cpu time, all 12GB of memory are in use plus a small amount of swap. Any actions with the desktop (opening K menu, trying to select among multiple Konsole windows, etc) are very slow, especially the first time (probably swapping back in). So I try to restart which also takes 15-20 seconds to bring up the Logout/Restart/Shutdown confirmation box. After a minute or so and much disk activity I sometimes get the KDE crash report tool for plasma-desktop. But it has crashed three days in a row now. Yesterday I tried to report it but could not get a login on this bug tracker with while the desktop was crashed. Today it did not give me the reporting tool. Through out the day the amount of memory in use continually grows even when the system is not being used but is logged in.

Reproducible: Always

Steps to Reproduce:
Restart system (after crash) in the morning and login. Use system normally and leave logged in for 24 hours. Then try to restart.


Actual Results:  
Desktop manager is crashed but system doesn't shutdown. Today I ssh into the system and saw the plasma-desktop in the processes table three times - 1. low process ID in the range of things running since startup, 2. on the command line of drkonqi, 3. plasma-dekstop --nocrashhandler. I killed the plasma-desktop processes and the system finished rebooting.

Expected Results:  
plasma-desktop should NOT suck up all the memory and CPU and it should exit cleanly when asked to.

Attached is the backtrace from yesterday's crash and a ps listing from today's crash. Other bugs citing a crash at logout or reboot were reported as fixed but were from much earlier versions of KDE/Qt/Plasma so I am submitting this bug against Fedora15 x86_64 fully patched, KDE 4.6.3, Qt 4.7.2, plasma 0.4. I saw memory usage grow any time the system was left running with Fedora 14 so added 8GB to the 4GB I had. Then the system sucked up all 12GB in a few days. So I upgraded to Fedora 15 and it just sucked up memory faster. In the past week the problems with the plasma-desktop started and now it crashes every day. So I believe the bug is in the latest version but it could be that an old bug has simply gotten worse.
Comment 1 Carl Schmidtmann 2011-07-01 13:15:06 UTC
*** Bug 276885 has been marked as a duplicate of this bug. ***
Comment 2 Carl Schmidtmann 2011-07-03 16:00:44 UTC
More information for tracking the cause of this problem:

All through the day the amount of CPU resource being used by plasma-desktop increases. Shortly after login it is alternating between 10-15% and 0.3% as reported by 'top'. After half a day it alternating between 50-60% and 5-10%. After about 24 hours it is alternating between 90-99% and 20-30%. These alterations appear to extremely consistent on the 3 second refresh rate of the 'top' command. Every other refresh of the screen the CPU % has switched between a high value (usually the highest of any process) and the lower level of CPU usage. So there is something in the plasma-desktop process that is cycling at a 6 second cycle rate.

As look today I noticed another process running at the same cycle - 'ksysguardd'. It is currently oscillating between 15-20% of CPU and 1% exactly 180 degrees from the plasma-desktop. This looks like some interaction between these two processes. Or it could be some other problem affecting both of these processes.
Comment 3 Carl Schmidtmann 2011-07-11 15:38:38 UTC
I have found a workaround for this bug. I had a second panel on the right hand side of the screen. I have had since Fedora 12. It mostly had the same components as the panel at the top of the screen. After deleting that second panel the problem with the plasma-desktop has gone away. I have not done the test of simply moving the default panel to the right side of the screen but I am guessing that the problem is having two panels or possibly the existence of two of the same components on the screen at the same time.

Of course now I am having issues with the knotify4 process going crazy. Yesterday it had, in a few hours, gone from 1-2GB of virtual memory to 13GB of virtual memory and over 3GB resident memory plus it was using 99% of a CPU's time.
Comment 4 Gregor Tätzner 2011-12-02 18:52:33 UTC
How is the situation?
Comment 5 Carl Schmidtmann 2011-12-02 20:42:35 UTC
Once I found the work around I have just continued on getting work done. I have not gone back to test having a second panel open with mostly the same gadgets/widgets/whatever in it.

The knotify4 process has settled down. If I remember correctly it sucked up lots of resources and then dialed back after a day or two. It has been many updates since and I haven't seen big problems with it.

Carl Schmidtmann
Comment 6 Martin Flöser 2013-05-28 18:39:32 UTC
Thank you for this crash report and helping to improve our software. Unfortunately we were not able to work on this specific report yet. Nowadays the version this crash was reported against is no longer maintained and this makes it very difficult to work on this report as the source code might have changed and the information in the backtrace is no longer valid.

Also it is quite likely that this problem got fixed in a later version. Crash reports are very often reported multiple times.

If you are able to reproduce this crash with the latest version of KDE Plasma (4.10.3) please reopen this report and adjust the version information in the dropdown above and please also include a new backtrace as generated by the crash reporting tool. Please also make sure that the steps on how to reproduce the crash are precise and correct. Thank you!