Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc 3.2.x OS: Linux When first logging in, KDED behaves normally (i.e. sits quietly in the background not using CPU). But when I start Kopete and enter my KWallet password, KDED suddenly starts eating 100% of the CPU. After killing and restarting kded, the problem seems to go away, even if the wallet has to be reopened.
In case you haven't seen this..
please break in with gdb (gdb kdeinit <pid of kded>) and provide a backtrace of where it is. you can get a backtrace by typing "where". Thanks
OK. One minor correction. Steps to reproduce this bug are as follows: - Login to KDE - Start Kopete and enter my Wallet password - Start Konqueror and visit a webpage that requires wallet data - Close Konqueror Kded begins eating the CPU. Here's the backtrace: #0 0x41455912 in select () from /lib/libc.so.6 #1 0x40f71b1c in __JCR_LIST__ () from /opt/qtcvs/lib/libqt-mt.so.3 #2 0x40aec1a6 in QEventLoop::enterLoop() () from /opt/qtcvs/lib/libqt-mt.so.3 #3 0x40aec048 in QEventLoop::exec() () from /opt/qtcvs/lib/libqt-mt.so.3 #4 0x40ad91a1 in QApplication::exec() () from /opt/qtcvs/lib/libqt-mt.so.3 #5 0x41b0ec79 in kdemain () from /opt/kdecvs/lib/libkdeinit_kded.so #6 0x408538ea in kdeinitmain () from /opt/kdecvs/lib/kde3/kded.so #7 0x0804d384 in launch(int, char const*, char const*, char const*, int, char const*, bool, char const*, bool, char const*) () #8 0x0804faa6 in main () #9 0x4139b767 in __libc_start_main () from /lib/libc.so.6 There does not appear to be anything in stdout/err related to the bug. I can send you the complete log if you think it will help.
Wow there is lots of corruption in KHTML when this happens. I still don't see the problem in kded but KHTML is indeed not looking good.
Interestingly enough, this bug (KDED CPU at 100%) also occurs when KNode tries to access the wallet.
Subject: Re: Kded uses 100% of the CPU on first Wallet access On Tuesday 23 September 2003 00:34, you wrote: > ------- Interestingly enough, this bug (KDED CPU at 100%) also occurs when > KNode tries to access the wallet. It seems that this might actually be kwin's fault. Still investigating... I can't reproduce it with the old kwin, but people are reporting this with the new kwin. When did you last update from CVS?
> When did you last update from CVS? A little over 24 hours ago. I'm planning on doing another update tonight (US/Pacific) when I get back from school.
Subject: Re: Kded uses 100% of the CPU on first Wallet access On Tuesday 23 September 2003 11:03, you wrote: > > When did you last update from CVS? > > A little over 24 hours ago. I'm planning on doing another update tonight > (US/Pacific) when I get back from school. That probably explains things. I bet it's kwin related now, based on what I've heard from other reports.
OK, I think you're right. I just noticed that kded, kwin AND X are all eating CPU at the moment. I don't know of anything specific I did to trigger it this time. Perhaps this should be sent over to the kwin people as well. Here's the backtrace from gdb attached to kded: #0 0x4145b912 in select () from /lib/libc.so.6 #1 0x40f77b1c in __JCR_LIST__ () from /opt/qtcvs/lib/libqt-mt.so.3 #2 0x40af21a6 in QEventLoop::enterLoop() () from /opt/qtcvs/lib/libqt-mt.so.3 #3 0x40af2048 in QEventLoop::exec() () from /opt/qtcvs/lib/libqt-mt.so.3 #4 0x40adf1a1 in QApplication::exec() () from /opt/qtcvs/lib/libqt-mt.so.3 #5 0x41b14c79 in kdemain () from /opt/kdecvs/lib/libkdeinit_kded.so #6 0x408588ea in kdeinitmain () from /opt/kdecvs/lib/kde3/kded.so #7 0x0804d384 in launch(int, char const*, char const*, char const*, int, char const*, bool, char const*, bool, char const*) () #8 0x0804faa6 in main () #9 0x413a1767 in __libc_start_main () from /lib/libc.so.6 Here's the backtrace from kwin: #0 0x4145b912 in select () from /lib/libc.so.6 #1 0x40f77b1c in __JCR_LIST__ () from /opt/qtcvs/lib/libqt-mt.so.3 #2 0x40af21a6 in QEventLoop::enterLoop() () from /opt/qtcvs/lib/libqt-mt.so.3 #3 0x40af2048 in QEventLoop::exec() () from /opt/qtcvs/lib/libqt-mt.so.3 #4 0x40adf1a1 in QApplication::exec() () from /opt/qtcvs/lib/libqt-mt.so.3 #5 0x41b3d6e7 in kdemain () from /opt/kdecvs/lib/libkdeinit_kwin.so #6 0x408588da in kdeinitmain () from /opt/kdecvs/lib/kde3/kwin.so #7 0x0804d384 in launch(int, char const*, char const*, char const*, int, char const*, bool, char const*, bool, char const*) () #8 0x0804e3dc in handle_launcher_request(int) () #9 0x0804e9c0 in handle_requests(int) () #10 0x0804f96f in main () #11 0x413a1767 in __libc_start_main () from /lib/libc.so.6 I didn't feel safe getting a backtrace from X... Interestingly enough, CPU usage went down to 0 when I was attached to kded, but remained at 100% when attached to kwin. Don't know if this tidbit helps any or not, but if it's a race/deadlock of some sort it might point in the right direction...
I see this problem also since new kwin. kded, kwin and X eating 100% of my CPU. Before CVS from manually killing kded and restarting it with --nofork option solved the problem. I see also a problem with eating up all my memory and swap, when I leave the system alone when kded eats my cpu. Thomas
Joshua: can you try to attach gdb to kded like you did before and then let it continue to run with "continue" and break it with ctrl-c, till "bt" gives a backtrace that looks significant different from the one you posted above?
I cannot reproduce the wallet problem with kopete, konqueror or knode. I also doubt it has actually anything to do with kwin. Moreover, the backtraces are useless, they just show the applications waiting in the eventloop for more events. Could you please try to get some useful backtrace from kded, as already explained by Waldo?
I have tried repeatedly to get a different backtrace, to no avail. (Stepping through just plain didn't work.) The closest I came was this... and it also looks to be in the Qt event handler: #0 0x4122a898 in write () from /lib/libpthread.so.0 #1 0x411feea4 in __JCR_LIST__ () from /usr/X11R6/lib/libX11.so.6 #2 0x4117093f in _X11TransWrite () from /usr/X11R6/lib/libX11.so.6 #3 0x411510f2 in _XFlushInt () from /usr/X11R6/lib/libX11.so.6 #4 0x41150f79 in _XFlush () from /usr/X11R6/lib/libX11.so.6 #5 0x41151708 in _XEventsQueued () from /usr/X11R6/lib/libX11.so.6 #6 0x41144a18 in XPending () from /usr/X11R6/lib/libX11.so.6 #7 0x40a8cd32 in QEventLoop::processEvents(unsigned) () from /opt/qtcvs/lib/libqt-mt.so.3 #8 0x40af21a6 in QEventLoop::enterLoop() () from /opt/qtcvs/lib/libqt-mt.so.3 #9 0x40af2048 in QEventLoop::exec() () from /opt/qtcvs/lib/libqt-mt.so.3 #10 0x40adf1a1 in QApplication::exec() () from /opt/qtcvs/lib/libqt-mt.so.3 #11 0x41b14c79 in kdemain () from /opt/kdecvs/lib/libkdeinit_kded.so #12 0x408588ea in kdeinitmain () from /opt/kdecvs/lib/kde3/kded.so #13 0x0804d384 in launch(int, char const*, char const*, char const*, int, char c onst*, bool, char const*, bool, char const*) () #14 0x0804faa6 in main () #15 0x413a1767 in __libc_start_main () from /lib/libc.so.6 I tried an strace as well (with the --nofork option), but couldn't reproduce the bug while stracing. I'll keep trying and see if I can come up with anything else.
I probably should have mentioned this earlier, though it only just now occurred to me that it might be important... when KDED eats CPU, at least 50% of that is spent in kernel-space (i.e. system cpu). So it is conceivable that a lot of that time could be spent repeatedly polling inside a select()... of course, I could be way off-base here too. This time kded started eating CPU even while still prompting for the wallet password. Here's the backtrace...though I imagine it doesn't show anything unexpected: #0 0x4145b912 in select () from /lib/libc.so.6 #1 0x40f77b1c in __JCR_LIST__ () from /opt/qtcvs/lib/libqt-mt.so.3 #2 0x40af21a6 in QEventLoop::enterLoop() () from /opt/qtcvs/lib/libqt-mt.so.3 #3 0x40adf201 in QApplication::enter_loop() () from /opt/qtcvs/lib/libqt-mt.so.3 #4 0x40cb6851 in QDialog::exec() () from /opt/qtcvs/lib/libqt-mt.so.3 #5 0x4204defe in KWalletD::internalOpen(QString const&, bool, unsigned long) () from /opt/kdecvs/lib/kde3/kded_kwalletd.so #6 0x4204ccfa in KWalletD::open(QString const&, unsigned) () from /opt/kdecvs/lib/kde3/kded_kwalletd.so #7 0x42055ac6 in KWalletD::process(QCString const&, QMemArray<char> const&, QCS tring&, QMemArray<char>&) () from /opt/kdecvs/lib/kde3/kded_kwalletd.so #8 0x4083d5c0 in DCOPClient::receive(QCString const&, QCString const&, QCString const&, QMemArray<char> const&, QCString&, QMemArray<char>&) () from /opt/kdecvs/lib/libDCOP.so.4 #9 0x40836bab in DCOPProcessInternal(DCOPClientPrivate*, int, unsigned long, QM emArray<char> const&, bool) () from /opt/kdecvs/lib/libDCOP.so.4 #10 0x4083655f in DCOPProcessMessage(_IceConn*, void*, int, unsigned long, int, IceReplyWaitInfo*, int*) () from /opt/kdecvs/lib/libDCOP.so.4 #11 0x40848431 in KDE_IceProcessMessages () from /opt/kdecvs/lib/libDCOP.so.4 #12 0x4083eed4 in DCOPClient::processSocketData(int) () from /opt/kdecvs/lib/libDCOP.so.4 #13 0x4084049b in DCOPClient::qt_invoke(int, QUObject*) () ---Type <return> to continue, or q <return> to quit--- from /opt/kdecvs/lib/libDCOP.so.4 #14 0x40b39b50 in QObject::activate_signal(QConnectionList*, QUObject*) () from /opt/qtcvs/lib/libqt-mt.so.3 #15 0x40b39cb0 in QObject::activate_signal(int, int) () from /opt/qtcvs/lib/libqt-mt.so.3 #16 0x40e517a2 in QSocketNotifier::activated(int) () from /opt/qtcvs/lib/libqt-mt.so.3 #17 0x40b55f30 in QSocketNotifier::event(QEvent*) () from /opt/qtcvs/lib/libqt-mt.so.3 #18 0x40adef55 in QApplication::internalNotify(QObject*, QEvent*) () from /opt/qtcvs/lib/libqt-mt.so.3 #19 0x40ade60b in QApplication::notify(QObject*, QEvent*) () from /opt/qtcvs/lib/libqt-mt.so.3 #20 0x406c4cb5 in KApplication::notify(QObject*, QEvent*) () from /opt/kdecvs/lib/libkdecore.so.4 #21 0x40aceb5a in QEventLoop::activateSocketNotifiers() () from /opt/qtcvs/lib/libqt-mt.so.3 #22 0x40a8ca2c in QEventLoop::processEvents(unsigned) () from /opt/qtcvs/lib/libqt-mt.so.3 #23 0x40af21a6 in QEventLoop::enterLoop() () from /opt/qtcvs/lib/libqt-mt.so.3 #24 0x40af2048 in QEventLoop::exec() () from /opt/qtcvs/lib/libqt-mt.so.3 #25 0x40adf1a1 in QApplication::exec() () from /opt/qtcvs/lib/libqt-mt.so.3 #26 0x41b14c79 in kdemain () from /opt/kdecvs/lib/libkdeinit_kded.so ---Type <return> to continue, or q <return> to quit--- #27 0x408588ea in kdeinitmain () from /opt/kdecvs/lib/kde3/kded.so #28 0x0804d384 in launch(int, char const*, char const*, char const*, int, char c onst*, bool, char const*, bool, char const*) () #29 0x0804faa6 in main () #30 0x413a1767 in __libc_start_main () from /lib/libc.so.6
No, sorry, those backtraces also aren't useful. Could you try to find out a way how to reproduce the problem with a fresh user, so that I have better chances reproducing it? Also, when this happens, could you check in 'top' which applications are active?
Subject: Re: Kded uses 100% of the CPU on first Wallet access On Thursday 25 September 2003 04:39, you wrote: > ------- Additional Comments From l.lunak@kde.org 2003-09-25 10:39 ------- > No, sorry, those backtraces also aren't useful. Could you try to find out a > way how to reproduce the problem with a fresh user, so that I have better > chances reproducing it? Also, when this happens, could you check in 'top' > which applications are active? Ah but be careful, don't erase your current setup in any way or you may not be able to reproduce it again. Backup files if you need to.
I have found out that the only way to reproduce this is to have klaptop running. I disabled klaptop for a couple of days and didn't see this problem anymore. Then I enabled it again (just to see my notebook battery status) and after a few minutes I had kded, kwin and X eating all of my cpu time. See this post on kde-devel mailing list talking about the same thing: http://lists.kde.org/?l=kde-devel&m=106435658526657&w=2 I hope this helps you to reproduce this problem.
Hmmm... I just noticed that klaptop seems to die whenever I kill kded and it's eating CPU. I hadn't noticed that before, but now that you point it out... I haven't yet had a chance to try to reproduce this. I'll do it tomorrow if I can (it's past midnight here already).
This can be the cause also at my machine. Also a laptop with klaptop and ACPI.
I discovered a couple new bits on this bug today, just in the normal course of using it. - KDED spiked today when I had nothing more than a terminal open (well, and the usual system tray stuff; KLaptop included), so I don't think it's directly KWallet's fault. KWallet does trigger the bug readily, however. - I can't seem to trigger the bug when KLaptop isn't open. But it's quite possible that I'm just not inventive enough. - KDED, KWin and X continue to eat CPU even after KLaptop is closed. I still haven't had a chance to test using a vanilla configuration. I'll try to do that today.
Subject: Re: Kded uses 100% of the CPU on first Wallet access On Monday 29 September 2003 17:35, you wrote: > ------- I discovered a couple new bits on this bug today, just in the > normal course of using it. > > - KDED spiked today when I had nothing more than a terminal open (well, and > the usual system tray stuff; KLaptop included), so I don't think it's > directly KWallet's fault. KWallet does trigger the bug readily, however. > > - I can't seem to trigger the bug when KLaptop isn't open. But it's quite > possible that I'm just not inventive enough. > > - KDED, KWin and X continue to eat CPU even after KLaptop is closed. > > I still haven't had a chance to test using a vanilla configuration. I'll > try to do that today. I see this locally on a Dell laptop as well. I have also seen kdesktop_lock using 100% cpu and ram
OK. Steps to consistently reproduce the bug: 1. Login to a fresh account (one that has never seen KDE before) 2. Accept all the defaults in the personalization wizard 3. Note that KLaptop is running in the system tray. 4. Start Konqueror, and visit a website that needs a username/password. Log in to the website. 5. Setup KWallet when prompted, using the basic setup. 6. Enter your KWallet password when prompted. 7. Check to see that your CPU usage is normal. Note that the wallet is unlocked. 8. Close Konqueror and note that the wallet is now locked. 9. Watch your CPU usage soar. Run 'top' and "enjoy". :) Steps for NOT reproducing the bug: Same as above, except for the following: 3. Check to see if KLaptop is running, and if so, close it. 9. Note that your CPU is continuing to idle. :) Hope this helps.
Bad luck. I don't have a laptop, and I cannot reproduce the problem :(.
*** Bug 65286 has been marked as a duplicate of this bug. ***
Also note that it currently doesn't seem to matter if the wallet subsystem is disabled in the KDE control center. However, that might be because the wallet subsystem doesn't honor the setting-- I notice the wallet icon showing up in my system tray even when I have it disabled.
Subject: Re: Kded uses 100% of the CPU on first Wallet access On Wednesday 01 October 2003 12:42, you wrote > ------- Also note that it currently doesn't seem to matter if the wallet > subsystem is disabled in the KDE control center. However, that might be > because the wallet subsystem doesn't honor the setting-- I notice the > wallet icon showing up in my system tray even when I have it disabled. How do you reproduce this?
Reproduce what? The wallet manager not respecting the control center setting? That would be a different bug but it can be reproduced by turning off the wallet manager in control center and noticing that the wallet icon pops up in the system tray anyway when you go to a site requiring a password.
Subject: Re: Kded uses 100% of the CPU on first Wallet access On Wednesday 01 October 2003 18:29, you wrote: > ------- Reproduce what? The wallet manager not respecting the control > center setting? That would be a different bug but it can be reproduced by > turning off the wallet manager in control center and noticing that the > wallet icon pops up in the system tray anyway when you go to a site > requiring a password. You'd better update your code and try again. I can't reproduce that behaviour at all.
Could people who can reproduce this bug please read http://lists.kde.org/?l=kde-core-devel&m=106511153216993&w=2 and so as it says? The rule about sending the result directly to me applies too, just please include the bugreport number in the mail. Also, it doesn't matter what kind of computer you have, the thing that matters is that you have this problem. The command for compiling should be something like g++ a.cpp -o a.out -I/usr/X11R6/include -I/opt/kde3/include -I/opt/qt3/include -L/opt/kde3/lib -L/opt/qt3/lib -lkdecore
Created attachment 2698 [details] qt patch Qt bug, triggered by klaptopdaemon's xautolock code.
*** Bug has been marked as fixed ***.
Building from CVS updated today this does _not_ seem to be fixed.
Subject: Re: Kded uses 100% of the CPU on first Wallet access On Saturday 11 October 2003 00:37, you wrote: > ------- Building from CVS updated today this does _not_ seem to be fixed. Did you update qt-copy?
Subject: Re: Kded uses 100% of the CPU on first Wallet access Quoting George Staikos <staikos@kde.org>: > ... > Did you update qt-copy? No, I didn't! I didn't realize I needed to! Sorry for the bother...
*** Bug 66218 has been marked as a duplicate of this bug. ***
*** Bug 66928 has been marked as a duplicate of this bug. ***
*** Bug 70754 has been marked as a duplicate of this bug. ***
*** Bug 74126 has been marked as a duplicate of this bug. ***
*** Bug 74917 has been marked as a duplicate of this bug. ***
*** Bug 78212 has been marked as a duplicate of this bug. ***
*** Bug 81144 has been marked as a duplicate of this bug. ***
*** Bug 81493 has been marked as a duplicate of this bug. ***
This still happens on Kubuntu Gutsy & Hardy on KDE 3.5.8 and 3.5.9, see https://bugs.launchpad.net/ubuntu/+source/kdelibs/+bug/86168 I'm using Kpowersave, not klaptop.
Yeah, unfortunately this or a similar bug is still present. I don't use KLaptop or such since this computer is not a laptop. The bug occurs when I log into KDE and seems to be associated with kwalletmanager (triggered by either Kontact or one of many Konqueror windows). Killing kded there and then seems to leave KDE unstable, so I quit KDE, kill the kded process from the console and then return. I'm running Gentoo x86_64, KDE 3.5.9, Qt 3.3.8/4.3.3, gcc 4.1.2, glibc 2.6.1.