kontact hangs on start, uses almost all CPU

Bug #148720 reported by Thomas Kluyver
6
Affects Status Importance Assigned to Milestone
kdepim (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: kdepim

Running kubuntu gutsy beta. Attempting to start kontact graphically:
- If it has not already got it, it requests access to my KDE wallet, which I give it, via the usual dialog.
- The bouncing icon on the cursor, and the hourglass taskbar-item, continue for a little while, then disappear
- A look at 'top' reveals that kontact is still running, and using most of my CPU.

Running from a command line gives the following output, after which it hangs with no window visible:

kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
WeaverThreadLogger: thread (ID: 4) suspended.
WeaverThreadLogger: thread (ID: 1) suspended.
WeaverThreadLogger: thread (ID: 2) suspended.
WeaverThreadLogger: thread (ID: 3) suspended.

Revision history for this message
Ramon de Ruiter (won) wrote :

Could you check with bug: 137401 to see if you have the same symptons?

Revision history for this message
Thomas Kluyver (takluyver) wrote :

Yes, I am noticing some of those things - the lag in QT applications drawing things, and the high CPU usage of XGL (my laptop's fan is flat out). I don't know how to check things like glxgears frame rate. See also my bug reports 147642 and, probably more relevant, 147637.

Revision history for this message
Thomas Kluyver (takluyver) wrote :

Could this be related to http://lists.debian.org/debian-qt-kde/2005/09/msg00240.html ?

I have definitely tried to set it up to connect to a secure LDAP server in the past. Loading up kaddressbook has similar consequences - the window does appear, but then it goes to maximum CPU usage and hangs. Loading KMail separately works (ish), but, as reported in the link above, it will hang after selecting a message to view.

Revision history for this message
Thomas Kluyver (takluyver) wrote :

I found the problem. Somehow, the LDAP server had been set up as a KDE resource, rather than an LDAP server in kaddressbook. As a result, loading kaddressbook made it start trying to load all the contacts from the LDAP server. Editing KDE resources from system settings solved the problem.

Revision history for this message
Holger Schletz (holger-schletz) wrote :

The last comment got me on the right track. Our directory is rather small, but the trouble began when I started populating the directory with jpegPhoto attributes (about 100k each).
Using kaddressbook's LDAP feature was non an option for me because it only allows importing an entry into an otherwise static adress book instead of getting an always up-to-date entry via LDAP.
I finally got around it by excluding the jpegPhoto attribute from the KDE ressource: go edit the ressource, click "edit attributes..." and remove the "jpegPhoto" entry. The only drawback is that KMail will no longer show me the photo in the Mail header. I can live without this :-)

Revision history for this message
tiger74 (fajarpri) wrote :

Hi, me too.
I'm upgrading from Feisty to Gutsy and Kontact uses all my cpu to the extend that I cannot use my computer anymore.
Then I'm checking my address book resource, and it turns out that it's pointing to an LDAP entries that is no longer there.
After I remove it, so far so good. Thank goodness. I hate to move to Thunderbird.

Revision history for this message
Richard Birnie (rbirnie-deactivatedaccount) wrote :

It sounds like we have a pretty good diagnosis of the problem. Does anyone still experience this bug in hardy or intrepid or has it been fixed?

thanks,
Richard

Changed in kdepim:
status: New → Incomplete
Revision history for this message
Thomas Kluyver (takluyver) wrote :

Well, we know what caused the immediate problem, and my guess is that if you were to set an LDAP server up as a resource, it may well do the same thing (I can't access my LDAP server until I'm back at uni in a bit over a week, so I can't test). But we don't know what it was that turned an LDAP server entry in Feisty into a KDE resource in Gutsy, which I'd consider the real bug. Hopefully it was something specific to that upgrade.

I'm planning to upgrade to Intrepid when it is in beta, so hopefully I'll be able to test then.

Revision history for this message
Richard Birnie (rbirnie-deactivatedaccount) wrote :

Any further news on this?

Revision history for this message
Thomas Kluyver (takluyver) wrote :

I did the upgrade, the problem did not present itself. I've just tried adding the LDAP server as a KDE resource manually, and I can't replicate the hanging behaviour. I guess it was a quirk of KDE3 that doesn't affect KDE4.

I'll set this as invalid (or should it be fix released?)

Changed in kdepim:
status: Incomplete → Invalid
Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Since it was fixed with an upgrade it can be marked Fix Released.

Changed in kdepim:
status: Invalid → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.