Okay, try this instead:

Code: Select all

killall kded4
sleep 30s
kded4 &

bcooksley wrote:Okay, try this instead:

Code: Select all

killall kded4
sleep 30s
kded4 &

That did it. It even restarted Blue Devil.

net@stimpy-laptop:~$ killall kded4
net@stimpy-laptop:~$ sleep 30s
net@stimpy-laptop:~$ kded4 &
[1] 11348
net@stimpy-laptop:~$ Failed to read classid file: Object not found
QDBusObjectPath: invalid path "/modules/muon-notifier"
kded(11349): The kded module name ' "muon-notifier" ' is invalid!
kded(11349)/kmix sink_input_cb: Ignoring sink-input due to it being designated as an event and thus handled by the Event slider
Agent registered
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
Object::connect: No such signal OrgFreedesktopModemManagerModemCdmaInterface::RegistrationStateChanged(const Solid::Control::ModemCdmaInterface::RegistrationState, const Solid::Control::ModemCdmaInterface::RegistrationState)
Object::connect: No such signal OrgFreedesktopModemManagerModemCdmaInterface::RegistrationStateChanged(const Solid::Control::ModemCdmaInterface::RegistrationState, const Solid::Control::ModemCdmaInterface::RegistrationState)
Object::connect: No such signal OrgFreedesktopModemManagerModemCdmaInterface::RegistrationStateChanged(const Solid::Control::ModemCdmaInterface::RegistrationState, const Solid::Control::ModemCdmaInterface::RegistrationState)
Object::connect: No such signal QDBusAbstractInterface::Changed()
/usr/bin/python: can't find '__main__' module in ''
kded(11349)/kmix sink_input_cb: Ignoring sink-input due to it being designated as an event and thus handled by the Event slider
^C
[1]+ Done kded4
net@stimpy-laptop:~$

Do you think there's anything of worth in this thread that I should add to the bug report?

-StewartM

Oh, and one other thing. When I deliberately cause this crash, after I issue those 3 commands:

$ killall kded4
$ sleep 30s
$ kded4 &

When I open the USB drive using Device Notifier it doesn't crash anymore! I tried it several times and it opens as it should.

However, if I unmount it and then re-insert it, and then open it using Device Notifier and Dolphin, I recreate the same crash.

-StewartM

Interesting. Do the same inconsistent system tray icons appear after the second crash?
Whatever causes this crash appears to introduce severe inconsistencies in two KDE processes: KDE Daemon and Plasma Desktop.

bcooksley wrote:Interesting. Do the same inconsistent system tray icons appear after the second crash?
Whatever causes this crash appears to introduce severe inconsistencies in two KDE processes: KDE Daemon and Plasma Desktop.

I think you misunderstand. The inconsistent system tray icons came after I caused the crash and then issued:

$ killall kded4 && kded4 &

When I type in instead:

$ killall kded4
$ sleep 30s
$ kded4 &

The icons come back as before. I don't have any more crashes after that on an already-mounted USB drive, even opening it using Device Notifier.

However, if I unmount the USB drive,then re-mount it and open it using Dolphin via the Device Notifier prompt, it will crash again.

Hope that makes it clear.

-StewartM

Ah, forgot to make clear what I was meaning by "inconsistent icons". I was referring to all the system tray crash notifications in this case.

And yes, only the second string of commands will work properly.

bcooksley wrote:I was referring to all the system tray crash notifications in this case.

Ah, then, to answer your question, yes, the crash notifications come back as before.

What I'm doing right now, however, is simply avoiding the crash by not using Device Notifier to open inserted USB drives. I open them directly via Dolphin instead.

-StewartM

Can you please get a copy of the Plasma backtrace and use that to report a bug at bugs.kde.org?

bcooksley wrote:Can you please get a copy of the Plasma backtrace and use that to report a bug at bugs.kde.org?

I've already reported the bug (it was already pre-existed, I added what I could to it).

However, this morning I got the March updates that took my system up to KDE 4.8.1. And presto!--the updates fixed the bug.

Not only that, albeit admittedly only after a few hours of use, kactivitymanager isn't eating up an ever-increasing amount of RAM (previously, it would start out at about 3-4 MB but could end up using up to 300 MB by day's end. Maybe that bug is fixed as well).

I'll mark this thread as "solved".

-stewartmm

I do not think that it is a good idea to close it. I did the update to 4.8.1 and this problem is appearing for me since. I will try later the solution to clean it and I was happy to see this post.

Please open a seperate thread for your issues, and please include screenshots as it is likely a similar, yet different issue.

I've found this discussion because I have the same problem with 4.8.3 (Kubuntu 12.04).
I'm not sure if it was the right bug, but I've filled a report here.