Bug 261255

Summary: some dead processes stay in the list
Product: [Unmaintained] ksysguard Reporter: Waleed Hamra <kdebugs>
Component: Process Controller - krunner partAssignee: KSysGuard Developers <ksysguard-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: alanbortu, amantia, captaincrutches, cfeck, commander.alchemy, dab1818, deabrufree, devguy.ca, ht990332, kdebugs, m01brv, markhkamp, martin.sandsmark, martin.tlustos, null, opensource, q.kde, rajindery, timshel, travisgevans
Priority: NOR    
Version: 4.8   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: http://commits.kde.org/libksysguard/c2fba0b64a0a2541a40a46a9f17fdbda1ea6a498 Version Fixed In:
Sentry Crash Report:
Attachments: Dead processes amarok and java (with detailed process information)
another screenshot for KDE 4.11.0 / Kubuntu 13.04
on left new instance of ksysguard, on right old one

Description Waleed Hamra 2010-12-25 22:58:18 UTC 
Version:           unspecified (using KDE 4.5.3) 
OS:                Linux

this doesnt happen to all processes, but to many of them.
when a process dies, either normal exit, or by forcibly killing it, it stays on top of the process list. htop has no record of it. an attempt to kill this ghost process apparntly gets ksysguard confused as to why it cant kill it, and asks me for sudo password, which i supply, and after trying to kill this non-existent process with root rights also fails, ksysguard complains about not enough privileges.
closing ksysguard and reopening it makes all these ghost processes disappear from list. but if i keep the program open long enough (several hours, i always keep it on), the list of ghost processes piles up.
this is a link to a snapshot:

http://img262.imageshack.us/img262/2452/ksysguard.jpg

as you can see, the top 2 in the list, are both ghost processes, i closed amarok and systemsettings long ago. kcmshell4 under bash was also closed long ago. same for the 2 soffice processes.

note: system monitor version 4.5.3, not sure why this number isn't in list of versions in this webpage.

Reproducible: Sometimes

Steps to Reproduce:
open system monitor (or ksysguard), keep it open. play with some programs, open few programs, and then close them. but mostly, just keep ksysguard running for few hours, and you'll notice it.

Actual Results:  
some processes that were ended, dont go off the list.

Expected Results:  
the dead processes should be removed from list.

OS: Linux (i686) release 2.6.32-27-generic
Compiler: cc
ksysguard 4.5.3
Comment 1 Christoph Feck 2011-10-04 11:25:04 UTC 
*** Bug 282974 has been marked as a duplicate of this bug. ***
Comment 2 Christoph Feck 2012-06-04 11:03:06 UTC 
*** Bug 301085 has been marked as a duplicate of this bug. ***
Comment 3 steveren 2012-09-15 12:22:25 UTC 
I've been seeing this for a long time in Fedora, and it's still happening in Fedora 17 with KDE 4.8.5
Comment 4 Konomi 2012-09-23 06:02:30 UTC 
I can confirm this has been happening for me on kde 4.6 to kde 4.8 it seems to persist endlessly across versions. I don't understand how this is not confirmed when I see it happening to every kde user I meet.
Comment 5 Roman 2012-09-27 08:56:11 UTC 
I suffer from the same issue. The only way to get rid of the ghost processes in the table is to restart ksysguard. It is already rather aged bug.
Comment 6 Travis Evans 2012-09-28 15:40:24 UTC 
I'm getting bit by this in KDE 4.8.4. I have several processes that don't even exist (they're not even in the /proc tree) persistently showing up as “disk sleep” in the CPU column. They refuse to go away. Attempting operations on them (send signal, show application window, etc.) just does nothing without an error message.

Anyone happen to see this in the latest version of KDE which I don't currently have installed?
Comment 7 Mark Haferkamp 2012-09-30 14:18:14 UTC 
I'm seeing this bug on my system running KDE 4.9.1 on Chakra Linux.

The following script to generate tons of processes hasn't resulted in any of them staying in the list after terminating, so the bug might depend on processes doing something specific.

#!/bin/bash
for ((i=0;i!=25000;i+=1)); do   # enough to fill the process table for a short while.
sleep 2 &                    # Give time for the process to appear in the list.
done
exit
Comment 8 Mark 2012-10-04 09:35:55 UTC 
@Waleed Hamra (or anyone that can confirm this bug, please attach a screenshot in here. The initial added image on imageshack is dead..
Comment 9 c2953420 2013-06-25 08:27:59 UTC 
Created attachment 80767 [details]
Dead processes amarok and java (with detailed process information)

I can also confirm this bug for KDE 4.10.3 / Kubuntu 13.04. In the attachment there are two dead processes, namely amarok and java. The detailed process information for java shows that it is actually not running.
Comment 10 Kirill 2013-08-18 10:52:41 UTC 
Created attachment 81768 [details]
another screenshot for KDE 4.11.0 / Kubuntu 13.04
Comment 11 Kirill 2013-08-18 11:03:18 UTC 
Comment on attachment 81768 [details]
another screenshot for KDE 4.11.0 / Kubuntu 13.04

confirm on KDE 4.11.0 / Kubuntu 13.04
dead processes are: thunderbird, kate, kwrite, dolphin, muon-updater
Comment 12 Zetok 2013-11-09 13:15:10 UTC 
Created attachment 83452 [details]
on left new instance of ksysguard, on right old one

I can confirm on Sabayon Linux with KDE 4.11.2.

Longer ksysguard runs, more processes are left on list - in screenshot below comparison between ksysguard running for ~2 days and freshly launched one.

Every process above systemd process doesn't exist.
Comment 13 Christoph Feck 2014-04-02 18:49:09 UTC 
*** Bug 332951 has been marked as a duplicate of this bug. ***
Comment 14 kdebugs 2014-04-02 19:35:28 UTC 
*** This bug has been confirmed by popular vote. ***
Comment 15 Artur O. 2014-04-20 16:15:27 UTC 
I got the same issue with KDE 4.13 on ArchLinux.
Comment 16 Hussam Al-Tayeb 2014-06-04 21:41:45 UTC 
Still in kde 4.13.1
Comment 17 Uzair Shamim 2014-09-27 23:44:22 UTC 
I still have this issue in KDE 4.14.1 on openSUSE Factory
Comment 18 Christoph Feck 2014-11-14 11:06:14 UTC 
*** Bug 340910 has been marked as a duplicate of this bug. ***
Comment 19 Dmitry A. Bakshaev 2014-12-06 18:01:24 UTC 
confirm on KDE 4.14.3 (ksysguard 4.11.14, gentoo linux)
Comment 20 Hussam Al-Tayeb 2015-01-20 21:22:41 UTC 
Is it possible that one of the developers may have some time to take a look at this, please? This is a 5+ year old bug.
Thank you very much for your time and for KDE.
Comment 21 Christoph Feck 2015-02-15 19:05:27 UTC 
To debug this, we need a way to reproduce it consistently. I have seen dead processes in the list, but I have no idea how I can reliably make them stay there to compare debug output and actual behavior.
Comment 22 steveren 2015-02-15 23:39:25 UTC 
(In reply to Christoph Feck from comment #21)
> To debug this, we need a way to reproduce it consistently.

Silly question, perhaps, but I have never seen ps give the wrong results, so would it not be possible to add some debug code that simply captured the output of ps, compared it to ksysguard's internal view and triggered a breakpoint if they differed?
Comment 23 Hussam Al-Tayeb 2015-02-15 23:47:35 UTC 
I think this is the code in question http://quickgit.kde.org/?p=ksysguard.git&a=blob&f=ksysguardd%2FLinux%2FProcessList.c
Comment 24 Christoph Feck 2015-11-12 23:16:41 UTC 
*** Bug 355182 has been marked as a duplicate of this bug. ***
Comment 25 Martin Tlustos 2016-01-18 09:14:07 UTC 
Some observations:
1) systemmonitor does not have this bug.
2) it only seems to happen if ksysguard is in the background or if you have switched to another tab.
Comment 26 Christoph Feck 2016-02-08 01:48:31 UTC 
*** Bug 359047 has been marked as a duplicate of this bug. ***
Comment 27 Mathieu Jobin 2016-05-18 02:21:28 UTC 
this is still valid as of ksysguard 5.6.4-1
running arch linux packages

closing and reopening ksysguard clears the list
Comment 28 Martin Sandsmark 2016-07-12 16:46:47 UTC 
Launching two instances of okular, and then closing them, reproduces it for me.
Comment 29 Martin Sandsmark 2016-07-12 17:06:03 UTC 
Launching ksysguardd from the command line and running "ps" doesn't seem to exhibit the same bug, so probably in the UI somehow.
Comment 30 Martin Sandsmark 2016-07-12 20:36:43 UTC 
The problem is somewhere in Processes::processesUpdated() in libksysguard, I think.

It seems to happen if a process appears and then disappears between calls to it.
Comment 31 Martin Sandsmark 2016-07-12 20:57:35 UTC 
It's a race condition between ProcessModelPrivate::updateWindowInfo() and Processes::processesUpdated().
Comment 32 Martin Sandsmark 2016-07-12 21:22:59 UTC 
https://git.reviewboard.kde.org/r/128431/
Comment 33 Martin Sandsmark 2016-07-16 15:12:03 UTC 
Git commit c2fba0b64a0a2541a40a46a9f17fdbda1ea6a498 by Martin T. H. Sandsmark.
Committed on 16/07/2016 at 15:10.
Pushed by sandsmark into branch 'master'.

Fix race condition when new applications open

When opening and closing an application quickly it sometimes got "stuck"
in ksysguard because it was added by ProcessModel while
Processes::processesUpdated() was running, so Processes never processed
it.
REVIEW: 128431

M  +0    -1    processui/ProcessModel.cpp

http://commits.kde.org/libksysguard/c2fba0b64a0a2541a40a46a9f17fdbda1ea6a498
Comment 34 Christoph Feck 2016-10-07 01:52:02 UTC 
*** Bug 370176 has been marked as a duplicate of this bug. ***