Summary: | Kopete hangs on startup if ~/.kde/share/app/kopete/ exists | ||
---|---|---|---|
Product: | [Unmaintained] kopete | Reporter: | uran238 |
Component: | Jabber Plugin | Assignee: | Kopete Developers <kopete-bugs-null> |
Status: | RESOLVED WORKSFORME | ||
Severity: | crash | CC: | mail, me |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | bt of kopete when it's frozen |
Description
uran238
2006-09-09 09:33:07 UTC
What are the contents of that folder when it's created? You can also try to get a backtrace for kopete by running "kill -SEGV <pid-of-kopete>" when it freezes. If that works, please paste the backtrace here Created attachment 17682 [details]
bt of kopete when it's frozen
Here's the bt. I recompiled kopete with debug information, thought it might be
usefull. If not, I have a backup.
The contents of the mentioned kopete folder are the files "contactlist.xml",
"jabber-capabilities-cache.xml" and the empty folder "jabberphotos"
Presumably this is a problem with the jabber bit of Kopete, but you might want to check if turning off any plugins helps (settings->configure plugins) Turning off all plugings doesn't change anything. But if I start kopete under valgrind (memcheck) it is slow as expected, but it won't freeze. Don't know why, but maybe it's a hint for you. I think this has something to do with the wallet. Kontact does hang like that as well, until I do 'killall kwalletmanager'. However I'm not 100% sure about the relevance with the wallet. It seems to have something to do with kwallet, but killing the walletmanager doesn't help. I have to deny Kopete to acess it, and enter my pwd manually. If Kopete tries to acess the wallet, (even no walletmanger will get startet,) it freezes. When I start kmail (which tries to acess the wallet), when Kopete is frozen, no window will get opened (but pids of kmail are in state sleeping) until I kill Kopete. I upgraded to kde-3.5.5 and the bug doesn't appear anymore, but is it really fixed? Hi, I had the same problem after updating from 3.5.3 to 3.5.5. After deleting ~/.kde/share/app/kopete/ kopete is working fine. Greetings RS Hi Ralph, I had to delete ~/.kde/share/app/kopete/ each time I startet kopete. Do you have the same problem, or is it sufficent to delete the folder once? Hi, yes it seems so. kopete is working fine until I use jabber. After using jabber kopete is very very slow and only the remove of the kopete-folder helps. Hi, I'm not sure but it seems to be a problem with the design. When I use the design retropete and not kopete, it seems to work without a crash. Greetings from Munich RS Turn off the jingle support and report back as to whether or not it continues to hang. It's not the Problem with Jingle, because Jingle was disabled. I enabled jingle in 0.12.3, but that version works with or without jingle support. Greetings Markus appears to be working now. please reopen if you start to have problems again Hi! I have this problem since early 3.5.5 and it's still present here. It doesn't appear always, What I can report, is: 1) Sometimes it happens almost always, other times I can start it ten times in a row without a problem. But normally it's hard to start it. 2) rm'ing .kde/share/apps/kopete increases the probability that it will start, but it's not sure anyway. 3) When it's run from konsole with all possible debugging messages turned on, it shows only libkopete: [void Kopete::ContactList::setSelectedItems(QPtrList<Kopete::MetaContact>, QPtrList<Kopete::Group>)] 0 metacontacts, 0 gr oups selected kopete: [void KopeteEditGlobalIdentityWidget::setIconSize(int)] Manually changing the icon size. When it starts OK, it then continues with kopete: [Kopete::Global::Properties::Properties()] and a lot of other messages from jabber (not using other protocols, just jabber). So I hope you can find at least approximate place of the freeze. 4) When gdb is attached, it shows it's waiting __lll_mutex_lock_wait () from libpthread. It's the same as in the bt already attached here. 5) I'm compiling kde regularly every week from the 3.5 branch SVN. I'm making a binary package and distributing it over about 5 machines I'm using. The problem appears only on some of them, which are the fastest and with dual-core CPUs. On slower, single-CPU machines it seems to work reliably. My conclusion is that this problem is caused by some kind of race. Please look at again, because kopete is much more better than, for example, centericq, which I should use now. I've also been experiencing this behaviour. Just upgraded to KDE 3.5.6 (on gentoo) and this time I got a crash instead: Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1209215312 (LWP 4747)] [KCrash handler] #6 0x4c22280c in operator>> (s=@0xbf88b120, str=@0x0) at tools/qcstring.cpp:2314 #7 0x4c5486d4 in DCOPProcessMessage (iceConn=0x81fb420, clientObject=0x82072d0, opcode=3, length=34, replyWait=0xbf88b908, replyWaitRet=0xbf88b1b4) at dcopclient.cpp:370 #8 0x4c55699f in KDE_IceProcessMessages (iceConn=0x81fb420, replyWait=0xbf88b2b8, replyReadyRet=0xbf88b308) at process.c:326 #9 0x4c54527c in DCOPClient::callInternal (this=0x81fc048, remApp=@0x8456698, remObjId=@0x84566a0, remFun=@0xbf88b424, data=@0xbf88b4a4, replyStruct=0xbf88b358, useEventLoop=false, timeout=-1, minor_opcode=2) at dcopclient.cpp:1931 #10 0x4c5454e2 in DCOPClient::callInternal (this=0x81fc048, remApp=@0x8456698, remObjId=@0x84566a0, remFun=@0xbf88b424, data=@0xbf88b4a4, replyType=@0xbf88b4f8, replyData=@0xbf88b4f0, useEventLoop=false, timeout=-1, minor_opcode=2) at dcopclient.cpp:1821 #11 0x4c545695 in DCOPClient::call (this=0x81fc048, remApp=@0x8456698, remObjId=@0x84566a0, remFun=@0xbf88b424, data=@0xbf88b4a4, replyType=@0xbf88b4f8, replyData=@0xbf88b4f0, useEventLoop=false, timeout=-1) at dcopclient.cpp:1765 #12 0x4c53dc3b in DCOPRef::callInternal (this=0x8456698, fun=@0xbf88b500, args=@0xbf88b4ac, data=@0xbf88b4a4, useEventLoop=NoEventLoop, timeout=-1) at dcopref.cpp:77 #13 0x4c53dc8d in DCOPRef::callInternal (this=0x8456698, fun=@0xbf88b500, args=@0xbf88b4ac, data=@0xbf88b4a4) at dcopref.cpp:52 #14 0x4cd768fe in DCOPRef::call<int, QString> (this=0x8456698, fun=@0xbf88b500, t1=@0x8478f8c, t2=@0xbf88b550) at ../../dcop/dcopref.h:523 #15 0x4cd72198 in KWallet::Wallet::hasFolder (this=0x8478f48, f=@0xbf88b550) at kwallet.cc:322 #16 0x410af382 in Kopete::WalletManager::slotWalletChangedStatus ( this=0x844f480) at kopetewalletmanager.cpp:119 #17 0x410af8f0 in Kopete::WalletManager::qt_invoke (this=0x844f480, _id=3, _o=0xbf88b658) at kopetewalletmanager.moc:97 #18 0x4bedb4ab in QObject::activate_signal (this=0x8478f48, clist=0x83d1240, o=0xbf88b658) at kernel/qobject.cpp:2356 #19 0x4bedb87f in QObject::activate_signal_bool (this=0x8478f48, signal=6, param=true) at kernel/qobject.cpp:2452 #20 0x4cd71730 in KWallet::Wallet::walletOpened (this=0x8478f48, t0=true) at kwallet.moc:132 #21 0x4cd7177d in KWallet::Wallet::walletOpenResult (this=0x0, id=0) at kwallet.cc:682 #22 0x4cd795fb in KWallet::Wallet::process (this=0x8478f48, fun=@0xbf88b944, data=@0xbf88b93c, replyType=@0xbf88b934, replyData=@0xbf88b92c) at kwallet_skel.cc:73 #23 0x4c543ed7 in DCOPClient::receive (this=0x81fc048, objId=@0xbf88b94c, fun=@0xbf88b944, data=@0xbf88b93c, replyType=@0xbf88b934, replyData=@0xbf88b92c) at dcopclient.cpp:1640 #24 0x4c547768 in DCOPProcessInternal (d=0x82072d0, opcode=1, key=1, dataReceived=@0xbf88b9f8, canPost=true) at dcopclient.cpp:518 #25 0x4c548604 in DCOPProcessMessage (iceConn=0x81fb420, clientObject=0x82072d0, opcode=1, length=68, replyWait=0x0, replyWaitRet=0xbf88ba64) at dcopclient.cpp:430 #26 0x4c55699f in KDE_IceProcessMessages (iceConn=0x81fb420, replyWait=0x0, replyReadyRet=0x0) at process.c:326 #27 0x4c544d19 in DCOPClient::processSocketData (this=0x81fc048, fd=3) at dcopclient.cpp:2009 #28 0x4c54850d in DCOPClient::qt_invoke (this=0x81fc048, _id=2, _o=0xbf88bc28) at ./dcopclient.moc:176 #29 0x4bedb4ab in QObject::activate_signal (this=0x82b5c60, clist=0x82b5d08, o=0xbf88bc28) at kernel/qobject.cpp:2356 #30 0x4bedc02a in QObject::activate_signal (this=0x82b5c60, signal=2, param=3) at kernel/qobject.cpp:2449 #31 0x4c2d8c37 in QSocketNotifier::activated (this=0x82b5c60, t0=3) at .moc/debug-shared-mt/moc_qsocketnotifier.cpp:85 #32 0x4bf0294a in QSocketNotifier::event (this=0x82b5c60, e=0xbf88bf8c) at kernel/qsocketnotifier.cpp:258 #33 0x4be66bdb in QApplication::internalNotify (this=0xbf88c21c, receiver=0x82b5c60, e=0xbf88bf8c) at kernel/qapplication.cpp:2635 #34 0x4be68b53 in QApplication::notify (this=0xbf88c21c, receiver=0x82b5c60, e=0xbf88bf8c) at kernel/qapplication.cpp:2358 #35 0x4c5fa34b in KApplication::notify (this=0xbf88c21c, receiver=0x82b5c60, event=0xbf88bf8c) at kapplication.cpp:550 #36 0x4bdf0dd7 in QApplication::sendEvent (receiver=0x82b5c60, event=0xbf88bf8c) at ../include/qapplication.h:496 #37 0x4be5736a in QEventLoop::activateSocketNotifiers (this=0x824d1a0) at kernel/qeventloop_unix.cpp:578 #38 0x4be07358 in QEventLoop::processEvents (this=0x824d1a0, flags=4) at kernel/qeventloop_x11.cpp:383 #39 0x4be84bf5 in QEventLoop::enterLoop (this=0x824d1a0) at kernel/qeventloop.cpp:198 #40 0x4be84a16 in QEventLoop::exec (this=0x824d1a0) at kernel/qeventloop.cpp:145 #41 0x4be6889f in QApplication::exec (this=0xbf88c21c) at kernel/qapplication.cpp:2758 #42 0x0806c300 in main (argc=) at main.cpp:107 #43 0x459f6838 in __libc_start_main (main=0x806bb70 <main>, argc=7, ubp_av=0xbf88c404, init=0x80c2000 <__libc_csu_init>, fini=0x80c1ff0 <__libc_csu_fini>, rtld_fini=0x459d1000 <_dl_fini>, stack_end=0xbf88c3fc) at libc-start.c:238 #44 0x0806bae1 in _start () I am getting this problem also and I get it under control starting kopete and going quick to right button on the icon, then set status and Offline. Then Kopete keeps working but it is not connected, after it I go to each protocol and start each one manually and it works fine. |