Version: 0.11.93 (0.12 Beta 2) (using KDE 3.5.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.16-suspend2-r1-justbudget i put it under crash because killing kopete is the only solution I have. I send a voice chat invitation. wait a bit. cancel the invitation. ask again. and kopete freeze for ever. although, if the chat go through it seems I can do more than one in a row.
this time I offered my friend a chat .... he did not see the invitation and kopete crashed. 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 16384 (LWP 8959)] [New Thread 32769 (LWP 9102)] [New Thread 229378 (LWP 9151)] [New Thread 245763 (LWP 9370)] [KCrash handler] #7 0xb4fd8a28 in XMPP::Client::streamReadyRead (this=0x83ff3b8) at client.cpp:512 #8 0xb4f99934 in XMPP::Client::qt_invoke (this=0x83ff3b8, _id=3, _o=0xbfead620) at im.moc.cpp:542 #9 0xb66286ac in QObject::activate_signal (this=0x842f418, clist=0x83c3f98, o=0xbfead620) at qobject.cpp:2355 #10 0xb6628504 in QObject::activate_signal (this=0x842f418, signal=4) at qobject.cpp:2324 #11 0xb4f979ef in XMPP::Stream::readyRead (this=0x0) at xmpp.moc.cpp:617 #12 0xb4fcc0fd in XMPP::ClientStream::doReadyRead (this=0x0) at stream.cpp:1280 #13 0xb4f9825e in XMPP::ClientStream::qt_invoke (this=0x842f418, _id=20, _o=0xbfead750) at xmpp.moc.cpp:888 #14 0xb66286ac in QObject::activate_signal (this=0x8252370, clist=0x8fcc088, o=0xbfead750) at qobject.cpp:2355 #15 0xb6a0bb47 in QSignal::signal (this=0x8252370, t0=@0x8252398) at moc_qsignal.cpp:100 #16 0xb664a56b in QSignal::activate (this=0x8252370) at qsignal.cpp:212 #17 0xb6654478 in QSingleShotTimer::event (this=0x8252348) at qtimer.cpp:286 #18 0xb65b8235 in QApplication::internalNotify (this=0xbfeadd60, receiver=0x8252348, e=0xbfeadab0) at qapplication.cpp:2635 #19 0xb65b7478 in QApplication::notify (this=0xbfeadd60, receiver=0x8252348, e=0xbfeadab0) at qapplication.cpp:2358 #20 0xb6e00ddf in KApplication::notify (this=0xbfeadd60, receiver=0x8252348, event=0xbfeadab0) at kapplication.cpp:550 #21 0xb7a4a62b in QApplication::sendEvent (receiver=0x0, event=0xb5f30a01) at qapplication.h:491 #22 0xb65a375f in QEventLoop::activateTimers (this=0x820d558) at qeventloop_unix.cpp:556 #23 0xb6553d5d in QEventLoop::processEvents (this=0x820d558, flags=4) at qeventloop_x11.cpp:389 #24 0xb65cf7d9 in QEventLoop::enterLoop (this=0x820d558) at qeventloop.cpp:198 #25 0xb65cf6f2 in QEventLoop::exec (this=0x820d558) at qeventloop.cpp:145 #26 0xb65b83d7 in QApplication::exec (this=0xbfeadd60) at qapplication.cpp:2758 #27 0x08075236 in main (argc=0, argv=0x0) at main.cpp:107 not sure if its same bug, but I'm posting here.
I encounter the same (voice call) bug in 0.12 (kde 3.5.2, gentoo-2.6.16-suspend2-r7, gcc 3.4.6): - if I (or the other party) call and the other party (or I) accepts, then either terminate, all is fine. case tested many times in a row (20+: works always?) - if I (or the other party) call and the other party (or I) rejects the call, then either terminate, kopete freezes (deadlock?). the freeze occurs either immediately (call window doesn't go away although call rejected by either one) or very soon later on (next action, mostly emitting/receiving a new call). kill -9 is the only solution. generally, the other party uses google talk, though I cannot guarantee it. this is 100% reproduceable.
kopete 0.12.3 (3.5.5). now the bug may go as far as preventing kopete to freeze at start. and as long as kopete is crashed, some other apps won't start (like kontact). building without jingle make things work again.
*** Bug 148998 has been marked as a duplicate of this bug. ***
Closing due to age. If you could confirm it's still present with a recent build and send an updated backtrace during a reopen that would be great. Cheers, Alan.