Version: (using KDE 4.2.90) OS: Linux Installed from: Ubuntu Packages After some time of normal desktop usage, the processes lancelot, dbus-daemon and kopete hog nearly all available cpu time. Even if I remove all instances of lancelot from the desktop (panels etc.), the processes keep running at ~98% together. If I kill the lancelot process manually, the other two calm down to normal.
How often does this happen? And, if often, after how much time (approx).
Same thing happening here with the kubuntu 4.3 beta 2 packages on Jaunty 9.04. I use lancelot and kopete but I don't think lancelot is the culprit. If i don't leave kopete running the issue never seems to happen but I haven't tested this for more than a few hours. I suspect kopete is trying to notify of something going on and is either causing the dbus-daemon to go nuts or something else is tying up dbus and then it can't handle what kopete wants to do. I quit kopete and after a 5 minutes or so things are back to normal. The cpu spike on lancelot is probably related to trying to open the menu and it can't open due to whatever dbus-daemon is doing (a guess). I also killed the nspluginviewer process but I can't tell if it's related to that even though it was showing some interaction with dbus. Starting kopete after 10 minutes or so when things were working normal causes the dbus-daemon, kopete and lancelot cpu spike. Also this is the dbus-daemon process owned by the user, not the root or messagebus owned one.
(In reply to comment #1) > How often does this happen? And, if often, after how much time (approx). In the last few days: every kde session. It happens after different time, sometimes 5min, usually ~20min. Is there some way to see what dbus is doing at that moment? Then I could post some logs...
I have no idea how to debug D-Bus calls... and, unfortunately, I can not reproduce this :( I'll add an option to disable the kopete integration until I figure this one out.
I can confirm this bug with the Kubuntu KDE 4.3beta2 packages. Without kopete lancelot behaves like normal.
*** Bug 196452 has been marked as a duplicate of this bug. ***
################################################### Until I succeed reproducing and fixing this issue, you can disable the Kopete support in Lancelot. To do so, open lancelotrc file: ~/.kde/share/config/lancelotrc And add the following line to the [Main] section imPlugins=disabled ###################################################
I added the: imPlugins=disabled to the lancelotrc file but yesterday had the same cpu spike and I had verified the Kopete contacts weren't showing in lancelot. When this happened I was messaging someone on a googletalk account and there were some new message notifications stacking up in Notifications and Jobs widget(?). I ended up with 2 notifications stuck in there and finally had to quit kopete and then restarted plasma to get rid of the notifications. Running Kubuntu 9.04 with the beta2 and qt 4.5.1
It happened again today, I disabled imPlugins and will see if the problem disappears. Ivan, do you have an idea about what we can do to help you when the bug occurs?
Unfortunately, it is not sufficient to do the imPlugins=disabled in beta2. It doesn't show the contacts, but it still does connect to kopete :( It will be in RC. (tagging is today) Is anyone able to compile L by hand? It occurred to me that L and Kopete are entering some king of endless loop or something... I'd add some debugging output to (hopefully) see where the bottleneck is.
I installed kdemod-testing packages yesterday (4.2.95) and had the same problem twice, yet. Will try disableing imPlugins
I can confirm the bug, using self-compiled 4.2.95 sources in gentoo (kde-testing overlay). To me it looks like it can be triggered very easily when kopete has a reconnect, then it starts to hog cpu :) I will try to disable the im-plugins and see if that helps.
Setting " imPlugins=disabled " in the lancelotrc helps, no more huge cpu usage.
I can confirm this bug with KDE 4.2.98 from openSUSE-repos (KDE4:Factory:Desktop). One way to trigger this is to disconnect or close Kopete, but sometimes it happens while doing nothing. If you say me how I could help I could compile lancelot by hand.
Still can't reproduce :( online/offline/online/exit/... but nothing For the compilation instructions, go to http://lancelot.fomentgroup.org/download
I've run dbus-monitor while disconnecting kopete this time. Kopete is sending an contactChanged for all contacts to the bus each containing all contact-data: signal sender=:1.388 -> dest=(null destination) path=/Kopete; interface=org.kde.Kopete; member=contactChanged [...] After this a process (:1.375, I think it is lancelot) is calling 3 methods to kopete for each contact 329(!) times: method call sender=:1.375 -> dest=org.kde.kopete path=/Kopete; interface=org.kde.Kopete; member=isContactOnline [...] method call sender=:1.375 -> dest=org.kde.kopete path=/Kopete; interface=org.kde.Kopete; member=getDisplayName [...] method call sender=:1.375 -> dest=org.kde.kopete path=/Kopete; interface=org.kde.Kopete; member=contactProperties [...] I think this is a lot and not neccessary. If you have a really full contact-list this will need a lot of time
Ok, that would explain why the CPU peeks, but it doesn't explain why it doesn't stabilize soon after that. I'll see to optimize it a bit, but it can't be a significant improvement (significant in some cases, but not in all). Did you notice whether Kopete sends updates only for the online contacts or for all?
If anyone could test the trunk version (at least take lancelot/app/src/models/ContactsKopete.cpp and lancelot/app/src/models/ContactsKopete.h from trunk) for improvements, I would very much appreciate it.
For me it stabilize after about a minute (3,2 GHz), If you have less CPU-time and a bigger contactlist it will take much more time. Why is Lancelot asking for the infos 329 times for each contact? Kopete sends the notification for all contacts, online and offline. I will see when I will have time to test the trunk, but I think this will not happen today.
Sorry, I ment "less CPU-power" in the last comment. I'm really missing an editing-function...
> For me it stabilize after about a minute (3,2 GHz), If you have less CPU-time > and a bigger contactlist it will take much more time. You're probably right on this one... (at least I hope since that would mean this report can be closed) The duplicated requests have been removed (a bug related to multiple calls of QObject::connect) and Lancelot now reacts to changes with a small delay so that it can aggregate the events when kopete sends a large amount of updates at once.
I've backported the changes from the trunk to 4.3 branch which means that you'll be able to test the changes in 4.3.1. This should do the trick - if the problem persists in 4.3.1, reopen this report.
*** Bug 198768 has been marked as a duplicate of this bug. ***
*** Bug 203523 has been marked as a duplicate of this bug. ***