Version: 1.1 (using KDE 3.4.2, Gentoo) Compiler: gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8) OS: Linux (i686) release 2.6.12-suspend2-r3 It occured just after the startup of KDE. And the first time I've seen this crash. Backtrace: Using host libthread_db library "/lib/libthread_db.so.1". `system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1229186880 (LWP 3409)] [KCrash handler] #4 KWalletD::internalOpen (this=0x8355bc8, appid=@0x835c804, wallet=@0x835c810, isPath=false, w=37748741) at kwalletbackend.h:102 #5 0xb65acffe in KWalletD::doTransactionOpen (this=0x8355bc8, appid=@0x835c804, wallet=@0x835c810, wId=37748741) at kwalletd.cpp:337 #6 0xb65abdc5 in KWalletD::processTransactions (this=0x8355bc8) at kwalletd.cpp:152 #7 0xb65b269a in KWalletD::qt_invoke (this=0x8355bc8, _id=7, _o=0xbfdfa5fc) at kwalletd.moc:100 #8 0xb7322893 in QObject::activate_signal (this=0x806e6b0, clist=0x81a1be0, o=0xbfdfa5fc) at qconnection.h:56 #9 0xb7657bd8 in QSignal::signal (this=0x806e6b0, t0=@0x0) at moc_qsignal.cpp:100 #10 0xb733c26f in QSignal::activate (this=0x806e6b0) at qsignal.cpp:212 #11 0xb73438d3 in QSingleShotTimer::event (this=0x806e688) at qtimer.cpp:286 #12 0xb72c6c7c in QApplication::internalNotify (this=0x0, receiver=0x806e688, e=0xbfdfaa74) at qapplication.cpp:2615 #13 0xb72c601d in QApplication::notify (this=0xbfdfad80, receiver=0x806e688, e=0xbfdfaa74) at qapplication.cpp:2372 #14 0xb791ed24 in KApplication::notify (this=0xbfdfad80, receiver=0x806e688, event=0xbfdfaa74) at kapplication.cpp:549 #15 0xb72b6749 in QEventLoop::activateTimers (this=0x814e708) at qeventloop_unix.cpp:555 #16 0xb7270ac7 in QEventLoop::processEvents (this=0x814e708, flags=4) at qeventloop_x11.cpp:389 #17 0xb72d8bd8 in QEventLoop::enterLoop (this=0x814e708) at qeventloop.cpp:198 #18 0xb72d8a88 in QEventLoop::exec (this=0x814e708) at qeventloop.cpp:145 #19 0xb72c6eb1 in QApplication::exec (this=0xbfdfad80) at qapplication.cpp:2758 #20 0xb7837580 in kdemain (argc=1, argv=0x805d800) at kded.cpp:897 #21 0xb78447ce in kdeinitmain (argc=1, argv=0x805d800) at kded_dummy.cpp:2 #22 0x0804ce10 in launch (argc=1, _name=0x804f5ab "kded", args=0x0, cwd=0x0, envc=0, envs=0x0, reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x804f517 "0") at kinit.cpp:626 #23 0x0804eb5b in main (argc=2, argv=0xbfdfb1c4, envp=0xbfdfb1d0) at kinit.cpp:1779
Based on that trace, you must either be out of memory and operator new is failing, kded is already corrupt from something else, or the backtrace is invalid.
Out of memory seems out of the question to me; 1G RAM + 1.5G swap, I've never run out of that before, except on the occasional severly memory leaking program. I did have a hanging (taking all processor time) kded yesterday. Though I'm not aware of anything special I'd installed lately that would touch kdebase stuff.
I think this has something todo with the fact that I had qt-3.3.5 installed. I'll be downgrading to the previous release, since KDE still has some problems with this version.
*** Bug 113958 has been marked as a duplicate of this bug. ***
Bug 113958 was a crash with qt-3.3.4 installed.
Hmm 2 years after I have exactly the same bug as described in Bug 113958 : ----------- I'm also having a somewhat related problem that somewhere between Kontact (KMail), Konqueror, Kate and Kopete KDED goes into CPU hogging mode if I don't answer the KWallet password prompt as fast as possible at desktop startup time. If it occurs I then need to kill kded and log out / back in. After which it usually doens't happen again that session. ----------- I'm using Debian Sid (currently with kde 3.5.8 and libqt3-mt 3.3.7-9). In fact I have this bug for a very long time. But now, it's more frequent than before, it happens on ~3/4 of my kde startup!
It doesn't happen on 3/4 of times, in fact this bug happens on *every* KDE startups! The only way do avoid it is to enter my wallet password very quickly (note that Henk Poley said the same thing about his Bug 113958 report). What could I do for a better report?
Apparently the pb comes from Kontact. Kded doesn't crash anymore since I remove Kontact from my KDE session. Now I have to launch it manually on each KDE startup (once KDEWallet password has been entered) but I prefer that.
I'm trying to reproduce this but can't. I tried the following procedure: 1) Closed my kwallet (using dcop) 2) Opened the wallet in kwalletmanager, kopete, kontact/kmail without actually entering the password 3) none of the programs show high cpu usage even if waiting I'm on debian sid as well with kded linked against libqt-mt.so.3.3.8. Could those still facing this problem please retry with the current version and if still applicable provide new instructions on how to reproduce?
Hi Michael, I'm on Debian unstable (kde 3.5.9) and I have still the pb. To reproduce it: - launch kontact - save kde session - restart kde session - wait a little (kontact need to be started I guess) - once password is entered in kdewallet, kded starts to eat 100% of CPU! Tell me if you want me to do something else.. Thanks, Vincent.
I might have gotten you wrong before. Are you saying that kded starts using CPU when the dialog for entering the password is already closed or it starts if you let the dialog open and don't enter the password fast enough?
Second option! I didn't try to close the KWallet dialog. Kded starts to eat CPU as soon as I enter the password in the KWallet dialog (and Kontact is already loaded). I hope to be clear..
@Vincent: Sorry, I still can't reproduce the problem you mention. I hope some day you will upgrade to KDE4 and it just disappears :-)
Yes, when KDE 4.1 is released that bug will become obsolete for me ;)
I'm closing this as with KDE 4.1 kwalletd is no longer part of kded thus eliminating this bug. Unfortunately current fixes can't be backported to 3.5.x as the architecture is quite different because of the DCOP->DBus switch.