Comments on: Troubleshooting kded4 Bugs

By: David Howells

David Howells — Wed, 31 Oct 2012 13:04:40 +0000

I’ve seen those, thanks, though I’m not sure how applicable they are since this is my desktop and I don’t suspend/resume it and the power management settings are all off.

By: kdepepo

kdepepo — Wed, 31 Oct 2012 12:08:29 +0000

David, you probably need to run kded4 with “–nofork” argument to make it appear in valgrind. Make sure it is not already running. Thanks for help with debugging it, but see also bugs 294497 and 306206.

By: David Howells

David Howells — Wed, 31 Oct 2012 10:55:16 +0000

Can you add a bit on how to valgrind kded4? I’m seeing kded4 gradually eating all my RAM, and if I could start it under valgrind, I could probably locate the problem fairly quickly.

By: hamelg

hamelg — Sun, 05 Jun 2011 17:00:48 +0000

Here, kdebugdialog helped me to find out a workaround.
When logging out my kde session, kded4 never terminates.
I enabled debug messages for kded with kdebugdialog and saw this message at logging out :
startkde: Done.
kded(25301) ObexFtpDaemon::offlineMode: Offline mode
kded4: Fatal IO error: client killed
kded(25301) LircClient::~LircClient: deleting theSocket

To fix that, I put a “sleep 1″ in my shutdown script in .kde4/shutdown directory.

By: Karellen

Karellen — Mon, 16 May 2011 13:20:23 +0000

Actually @anon, you might be better off switching to a real console and attaching to kded4 with gdb. That way you could pause it and check the stack a number of times, and also inspect the loop that it’s in, and dump memory if required.

By: anon too

anon too — Mon, 16 May 2011 09:01:19 +0000

Small trick when you have a process using CPU for no good reason:

Enable core dumps, and then “kill -SEGV” the offender. Save the dump, and analyse it later. At the very least, you’re likely to get a backtrace going through the problematic code.

By: Achim Bohnet

Achim Bohnet — Thu, 12 May 2011 14:46:24 +0000

Thx for the description of kded4 bug hunting.

But it unfortunately confirms me in my impression and experience that kded4 bug hunting is ‘too time consuming’ I’ve more or less given up (shame on me) and try if logout/in or reboot fixes kde4d. This has the bad taste of ‘like-windows’ but it works

IMHO it’s necessary to improve either robustness of the kde4d system (e.g. kdeinit+forking) or via and/or add debug helpers, to e.g. top
like interface that show module: wake ups/sec and % cpu or maybe a use SIGUSR1 that prints out currently running module.

By: jbernardo

jbernardo — Thu, 12 May 2011 04:52:55 +0000

@kdepepo In the end I had to edit /usr/share/kde4/services/kded/networkstatus.desktop and set X-KDE-Kded-autoload=false and X-KDE-Kded-load-on-demand=false to get kded4 not to hang with 100% cpu on vpn or broadband disconnection, just stopping and disabling the startup services wasn’t enough, the module would still get loaded making it impossible to pinpoint the “culprit”. Seems like this is one of the modules that keeps auto-loading even if disabled in the startup services.
Thanks for the guide, lets see now if I can add anything to the bug reports.

By: anon

anon — Wed, 11 May 2011 21:36:12 +0000

@Ami

I guess on a desktop it’s a “worthy tradeoff”. But remember, KDE does *not* run on simply one platform.

And having “modules per process” would be a shitload of work for what payoff? Then those codepaths would have to be maintained, no less…

Doesn’t make sense, imo.

By: Ami

Ami — Wed, 11 May 2011 12:19:13 +0000

@kdepepo, 50MB is a lot of memory, nevertheless for a desktop/laptop system with > 2GB RAM, 50MB is a worthy tradeoff for a seperate process mode like @Karellen suggested. I prefer having less memory but being able to hunt down and stop problematic Kded components.

Do you think it would be possible to have a module-per-process model (even for debug/testing purposes)?