Bug 126036 - kopete freeze waiting for voice on second time
Summary: kopete freeze waiting for voice on second time
Status: RESOLVED WORKSFORME
Alias: None
Product: kopete
Classification: Unmaintained
Component: Jabber Plugin (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR crash
Target Milestone: ---
Assignee: Kopete Developers
URL:
Keywords:
: 148998 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-04-21 17:34 UTC by Mathieu Jobin
Modified: 2008-12-29 11:28 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Jobin 2006-04-21 17:34:50 UTC
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.
Comment 1 Mathieu Jobin 2006-04-22 02:16:47 UTC
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.
Comment 2 Lloeki 2006-07-12 09:55:03 UTC
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.
Comment 3 Lloeki 2006-10-18 10:59:41 UTC
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.
Comment 4 Christophe Marin 2008-07-03 16:53:56 UTC
*** Bug 148998 has been marked as a duplicate of this bug. ***
Comment 5 Alan Jones 2008-12-29 11:28:24 UTC
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.