Application that crashed: kopete Version of the application: 0.70.85 KDE Version: 4.2.85 (KDE 4.2.85 (KDE 4.3 Beta1)) Qt Version: 4.5.1 Operating System: Linux 2.6.29-custom i686 What I was doing when the application crashed: As soon as Bonjour logs in kopete crashes and the only way to restore kopete is to remove the bonjour entry on kopeterc file. When there are no other computers on the network using bonjour this does not happen (tested this alone at home). Not sure if this is a duplicate of the other bug as the backtrace is different. Cheers, -- Backtrace: Application: Kopete (kopete), signal: Segmentation fault [Current thread is 0 (LWP 3029)] Thread 4 (Thread 0xb1759b90 (LWP 3077)): #0 0xb6ab01b0 in __i686.get_pc_thunk.bx () from /lib/libpthread.so.0 #1 0xb6ab4d4c in __pthread_mutex_unlock_usercnt () from /lib/libpthread.so.0 #2 0xb56f4d13 in ?? () from /usr/lib/libglib-2.0.so.0 #3 0x08959ac4 in ?? () #4 0x7fffffff in ?? () #5 0x0864da48 in ?? () #6 0x00000001 in ?? () #7 0x00000001 in ?? () #8 0xb578d9c8 in ?? () from /usr/lib/libglib-2.0.so.0 #9 0xb578d5f8 in ?? () from /usr/lib/libglib-2.0.so.0 #10 0xb6ab6c15 in pthread_getspecific () from /lib/libpthread.so.0 #11 0xb56f5321 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #12 0xb6c853a8 in QEventDispatcherGlib::processEvents (this=0x86ab480, flags={i = -1317694792}) at kernel/qeventdispatcher_glib.cpp:326 #13 0xb6c4a94c in QEventLoop::processEvents (this=0x86caf68, flags={i = -1317694728}) at kernel/qeventloop.cpp:149 #14 0xb6c4ab6d in QEventLoop::exec (this=0x86caf68, flags={i = -1317694632}) at kernel/qeventloop.cpp:200 #15 0xb1e51e67 in QCA::SyncThread::run () from /usr/local/kde4/lib/libqca.so.2 #16 0xb6b36592 in QThreadPrivate::start (arg=0x86f8478) at thread/qthread_unix.cpp:189 #17 0xb6ab2310 in start_thread () from /lib/libpthread.so.0 #18 0xb5c97bee in clone () from /lib/libc.so.6 Thread 3 (Thread 0xb0f59b90 (LWP 3079)): #0 0xb5791fdc in clock_gettime () from /lib/librt.so.1 #1 0xb6c883f3 in QTimerInfoList::getTime (this=0x8817a14, t=@0x8817a38) at kernel/qeventdispatcher_unix.cpp:339 #2 0xb6c885f0 in QTimerInfoList::updateCurrentTime (this=0x8817a14) at kernel/qeventdispatcher_unix.cpp:297 #3 0xb6c88d72 in QTimerInfoList::timerWait (this=0x8817a14, tm=@0xb0f5917c) at kernel/qeventdispatcher_unix.cpp:420 #4 0xb6c86474 in timerSourcePrepare (source=0x88179e0, timeout=0xb0f591d8) at kernel/qeventdispatcher_glib.cpp:140 #5 0xb56f49c2 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0 #6 0xb56f4e4a in ?? () from /usr/lib/libglib-2.0.so.0 #7 0x088f1548 in ?? () #8 0xb0f59248 in ?? () #9 0x0887a7f0 in ?? () #10 0x00000001 in ?? () #11 0x00000001 in ?? () #12 0xb578d9c8 in ?? () from /usr/lib/libglib-2.0.so.0 #13 0xb578d5f8 in ?? () from /usr/lib/libglib-2.0.so.0 #14 0xb6ab6c15 in pthread_getspecific () from /lib/libpthread.so.0 #15 0xb56f5321 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #16 0xb6c853a8 in QEventDispatcherGlib::processEvents (this=0x8981af8, flags={i = -1326083368}) at kernel/qeventdispatcher_glib.cpp:326 #17 0xb6c4a94c in QEventLoop::processEvents (this=0x89a73f0, flags={i = -1326083304}) at kernel/qeventloop.cpp:149 #18 0xb6c4ab6d in QEventLoop::exec (this=0x89a73f0, flags={i = -1326083236}) at kernel/qeventloop.cpp:200 #19 0xb203c6df in XMPP::SyncThread::run (this=0x88c2b50) at /usr/local/kde4/src/KDE/kdenetwork/kopete/protocols/jabber/libiris/iris/irisnet/corelib/netinterface.cpp:151 #20 0xb6b36592 in QThreadPrivate::start (arg=0x88c2b50) at thread/qthread_unix.cpp:189 #21 0xb6ab2310 in start_thread () from /lib/libpthread.so.0 #22 0xb5c97bee in clone () from /lib/libc.so.6 Thread 2 (Thread 0xb0759b90 (LWP 3086)): #0 0xb6ab5da0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0xb6b370b2 in QWaitConditionPrivate::wait (this=0x8dc3888, time=4294967295) at thread/qwaitcondition_unix.cpp:87 #2 0xb6b36b19 in QWaitCondition::wait (this=0x8dc3610, mutex=0x8dc360c, time=4294967295) at thread/qwaitcondition_unix.cpp:159 #3 0xb747d00f in QHostInfoAgent::run (this=0x8dc3600) at kernel/qhostinfo.cpp:260 #4 0xb6b36592 in QThreadPrivate::start (arg=0x8dc3600) at thread/qthread_unix.cpp:189 #5 0xb6ab2310 in start_thread () from /lib/libpthread.so.0 #6 0xb5c97bee in clone () from /lib/libc.so.6 Thread 1 (Thread 0xb51a2b10 (LWP 3029)): [KCrash Handler] #5 0xb7d27fd6 in QBasicAtomicInt::deref () from /usr/local/kde4/lib/libqimageblitz.so.4 #6 0xb6b8b0bc in QString::operator= (this=0x89034c0, other=@0x8f09f78) at tools/qstring.cpp:1130 #7 0xb747ca8f in QHostAddressPrivate::operator= (this=0x89034a8) at kernel/qhostaddress.cpp:106 #8 0xb74797be in QHostAddress::operator= (this=0x8893d24, address=@0xbf97bfd8) at kernel/qhostaddress.cpp:571 #9 0xafeb2005 in BonjourContact::setremoteAddress (this=0x8893d08, nremoteAddress=@0xbf97bfd8) at /usr/local/kde4/src/KDE/kdenetwork/kopete/protocols/bonjour/bonjourcontact.cpp:162 #10 0xafeb4ca3 in BonjourAccount::comingOnline (this=0x9106c70, pointer={d = 0xbf97c0c4}) at /usr/local/kde4/src/KDE/kdenetwork/kopete/protocols/bonjour/bonjouraccount.cpp:265 #11 0xafeb4ff9 in BonjourAccount::qt_metacall (this=0x9106c70, _c=QMetaObject::InvokeMetaMethod, _id=1, _a=0xbf97c1dc) at /usr/local/kde4/build/KDE/kdenetwork/kopete/protocols/bonjour/bonjouraccount.moc:94 #12 0xb6c690c4 in QMetaObject::activate (sender=0x92629e8, from_signal_index=4, to_signal_index=4, argv=0xbf97c1dc) at kernel/qobject.cpp:3111 #13 0xb6c6a71c in QMetaObject::activate (sender=0x92629e8, m=0xafe86350, local_signal_index=0, argv=0xbf97c1dc) at kernel/qobject.cpp:3185 #14 0xafe74a59 in DNSSD::ServiceBrowser::serviceAdded (this=0x92629e8, _t1={d = 0xbf97c218}) at /usr/local/kde4/build/KDE/kdelibs/dnssd/servicebrowser.moc:85 #15 0xafe75062 in DNSSD::ServiceBrowserPrivate::gotNewService (this=0x8ae1860, name=@0x908e700, type=@0x93f36f8, domain=@0xa693828) at /usr/local/kde4/src/KDE/kdelibs/dnssd/avahi-servicebrowser.cpp:121 #16 0xafe75624 in DNSSD::ServiceBrowserPrivate::qt_metacall (this=0x8ae1860, _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0xbf97c364) at /usr/local/kde4/build/KDE/kdelibs/dnssd/avahi-servicebrowser_p.moc:77 #17 0xb6c690c4 in QMetaObject::activate (sender=0x91d0488, from_signal_index=8, to_signal_index=8, argv=0xbf97c364) at kernel/qobject.cpp:3111 #18 0xb6c6a71c in QMetaObject::activate (sender=0x91d0488, m=0xafe86884, local_signal_index=3, argv=0xbf97c364) at kernel/qobject.cpp:3185 #19 0xafe81589 in OrgFreedesktopAvahiServiceBrowserInterface::ItemNew (this=0x91d0488, _t1=4, _t2=0, _t3=@0x908e700, _t4=@0x93f36f8, _t5=@0xa693828, _t6=5) at /usr/local/kde4/build/KDE/kdelibs/dnssd/avahi_servicebrowser_interface.moc:116 #20 0xafe81731 in OrgFreedesktopAvahiServiceBrowserInterface::qt_metacall (this=0x91d0488, _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0xbf97c440) at /usr/local/kde4/build/KDE/kdelibs/dnssd/avahi_servicebrowser_interface.moc:82 #21 0xb6d9a751 in QDBusConnectionPrivate::deliverCall (this=0x9076ef0, object=0x91d0488, msg=@0x92a83c4, metaTypes=@0x92a83c8, slotIdx=8) at qdbusintegrator.cpp:891 #22 0xb6da8879 in QDBusCallDeliveryEvent::placeMetaCall (this=0x92a8398, object=0x91d0488) at qdbusintegrator_p.h:101 #23 0xb6c665b8 in QObject::event (this=0x91d0488, e=0x92a8398) at kernel/qobject.cpp:1109 #24 0xb5f83ed4 in QApplicationPrivate::notify_helper (this=0x8265130, receiver=0x91d0488, e=0x92a8398) at kernel/qapplication.cpp:4057 #25 0xb5f84273 in QApplication::notify (this=0xbf97e7d0, receiver=0x91d0488, e=0x92a8398) at kernel/qapplication.cpp:3604 #26 0xb71d17e3 in KApplication::notify (this=0xbf97e7d0, receiver=0x91d0488, event=0x92a8398) at /usr/local/kde4/src/KDE/kdelibs/kdeui/kernel/kapplication.cpp:307 #27 0xb6c4e342 in QCoreApplication::notifyInternal (this=0xbf97e7d0, receiver=0x91d0488, event=0x92a8398) at kernel/qcoreapplication.cpp:610 #28 0xb78d3bd0 in QCoreApplication::sendEvent () from /home/morphbr/install/qt-4.5.1/lib/libQt3Support.so.4 #29 0xb6c4e8f4 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x8238840) at kernel/qcoreapplication.cpp:1247 #30 0xb6c4eb8c in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1140 #31 0xb7973741 in QCoreApplication::sendPostedEvents () from /home/morphbr/install/qt-4.5.1/lib/libQt3Support.so.4 #32 0xb6c8624e in postEventSourceDispatch (s=0x8255720) at kernel/qeventdispatcher_glib.cpp:209 #33 0xb56f1ac8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #34 0xb56f5163 in ?? () from /usr/lib/libglib-2.0.so.0 #35 0x08255698 in ?? () #36 0x00000000 in ?? ()
Yes, one of the other clients does something which crashes bonjour. Arthur, can you tell me the other bonjour clients which are running on your lan? Running "avahi-browse -rt _presence._tcp" and pasting the output here would be helpful
This seems to be a duplicate of bug 177487 (same situation, *same* backtrace) However as Tejas Dinkar already asked here I'm not going to mark it. Thanks
Hi Tejas, this is the output of the command you requested: eth0 IPv6 anselmolsm@skadi iChat Presence local + eth0 IPv4 anselmolsm@skadi iChat Presence local + eth0 IPv4 luwolf@bobesponja iChat Presence local + eth0 IPv4 Marcelo "Setanta"@lovecraft iChat Presence local + eth0 IPv4 Marcelo Setanta@azevedo iChat Presence local + eth0 IPv4 patifa@Patifa iChat Presence local + eth0 IPv4 Etrunko@etrunko-desktop iChat Presence local = eth0 IPv6 anselmolsm@skadi iChat Presence local hostname = [skadi.local] address = [fe80::21e:37ff:fe84:51e2] port = [5298] txt = ["ver=0.0.1" "vc=!" "txtvers=1" "status=avail" "port.p2pj=5298" "node=kopete" "last" "email=anselmo.lacerda@domain.org" "1st=Anselmo"] = eth0 IPv4 anselmolsm@skadi iChat Presence local hostname = [skadi.local] address = [192.168.5.44] port = [5298] txt = ["ver=0.0.1" "vc=!" "txtvers=1" "status=avail" "port.p2pj=5298" "node=kopete" "last" "email=anselmo.lacerda@domain" "1st=Anselmo"] = eth0 IPv4 luwolf@bobesponja iChat Presence local hostname = [bobesponja.local] address = [192.168.4.62] port = [5298] txt = ["1st=Luciano" "port.p2pj=5298" "last=Wolf" "status=dnd" "txtvers=1" "email=lucianomw@domain.com" "nick=Luck" "phsh=b42187709a534f60867bca5fd212607f99185955" "msg=" "jid="] = eth0 IPv4 Marcelo "Setanta"@lovecraft iChat Presence local hostname = [lovecraft.local] address = [192.168.5.166] port = [5298] txt = ["nick=setanta" "port.p2pj=5298" "email=marcelo.lira@domain.org" "jid=marcelo.lira@domain.org" "txtvers=1" "1st=Marcelo" "last=Lira" "msg=" "status=away"] = eth0 IPv4 Marcelo Setanta@azevedo iChat Presence local hostname = [azevedo.local] address = [192.168.5.126] port = [5298] txt = ["1st=Marcelo" "port.p2pj=5298" "last=Lira" "status=away" "txtvers=1" "email=marcelo.lira@domain.org" "nick=setanta" "phsh=5e9fc7c31062596717a1ce96d11b190565881587" "msg=" "jid=marcelo.lira@domain.org"] = eth0 IPv4 patifa@Patifa iChat Presence local hostname = [Patifa.local] address = [192.168.5.30] port = [5298] txt = ["last=Montenegro" "port.p2pj=5298" "msg=LRRTM1" "email=patricia.montenegro@domain.org" "AIM=pmontenegro@mac.com" "1st=Patricia" "jid=pmontenegro@domain.com" "vc=CUAV!" "phsh=bb77e1b350854721f4176f5ba2859f8e71f947e7" "status=avail" "txtvers=1"] = eth0 IPv4 Etrunko@etrunko-desktop iChat Presence local hostname = [etrunko-desktop.local] address = [192.168.4.54] port = [5298] txt = ["msg=" "1st=Eduardo" "txtvers=1" "port.p2pj=5298" "status=avail" "last=Lima" "nick=Etrunko"]
Was this bug fixed? Can you guys recheck it? I had this problem in the past, but now It's working here: kopete r992849 KDE trunk: r992924 - 4.3.60 (KDE 4.3.60 (KDE 4.4 >= 20090706)) qt from kde-qt: fad3c7 avahi-0.6.25 on gentoo linux - 2.6.29-tuxonice-r3
SVN commit 1000243 by dinkar: Added explicit constructors for objects in classes in Bonjour This should fix the ugly segfaulting that has been happening for some people. (see the bug list below). CCBUG: 177487 CCBUG: 192087 M +2 -6 bonjouraccount.cpp M +6 -5 bonjouraddcontactpage.h M +2 -19 bonjourcontact.cpp M +1 -6 bonjourcontact.h M +2 -4 bonjourcontactconnection.cpp M +0 -1 bonjoureditaccountwidget.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1000243
Fixed here. Thanks :)
*** Bug 205961 has been marked as a duplicate of this bug. ***
@Tejas Dinkar: it seems the fix was not backported to 4.3.x; can it be done ? Thanks
The patch was backported (1000246), but it still doesn't seem to fix anything. This is a really really dodgy bug. I'd appreciate ANY help on this, even if it is just figuring out what causes it.
*** Bug 207112 has been marked as a duplicate of this bug. ***
Check bug 207489 for an updated backtrace of this crash on 4.3.68. Thanks
*** Bug 207489 has been marked as a duplicate of this bug. ***
Created attachment 37525 [details] possible fix for seg faulting I am experiencing this problem under fedora, even with the above mentioned revision 1000243. It appears to seg fault still when the new metacontact already exists, so the bonjour contact gets appended to the existing metacontact, and then bonjouraccount.cpp just grabs the first one and casts it to BonjourContact (but the first contact in the metacontact happens to be a jabber contact). Here i've used findContact instead. The comment above it *appears* to relate to the hack so i've removed it also. Can somebody confirm that this is an appropriate fix (especially considering the comment that I removed), and then i'll commit it to trunk (i've only tested on the source rpm that cames from fedora, but from my zero experience inside kopete, I don't foresee any problems). Cheers James
Although I'm not entirely sure that patch will fix this particular bug, that patch is very useful in fixing a hack I did when I first wrote the plugin (and the behaviour of kopete was slightly different in that it didn't club people with the same name). Please commit
SVN commit 1034486 by hogan: Fix kopete bonjour plugin handling of new contact added to existing metacontact. When a bonjour contact becomes visible for whom a metacontact already exists, it would try and cast the first contact in the metacontact to BonjourContact even if it was for example a JabberContact, resulting in a segfault. The fix uses mc->findContact to find the new contact without making assumptions about it's position inside the metacontact. CCBUG: 177487 CCBUG: 192087 M +4 -3 bonjouraccount.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1034486
Bug 212983 is really similar but it has "BonjourContact::setremoteHostName" instead of "BonjourContact::setremoteAddress". @James: did your commit fixed this ? Should the report be closed ? Thanks
*** Bug 212983 has been marked as a duplicate of this bug. ***
@Dario: My commit fixed the problem for me, and the symptoms originally described do match the problem fixed by the commit, but i haven't had any confirmation that it has definitely fixed it for others. I would say the report can be closed.
Ok, closing as FIXED. Please reopen this report if you experience those crashes with KDE SC 4.4+
If i remember right, the actual function that it seg faulted in (BonjourContact::setremoteHostname or whatever), could vary, as the problem was that it was treating a different type of contact (e.g. a JabberContact) as a BonjourContact.
Then I guess it is the same. Thanks for the explanation :)
This bug has haunted me for about two years now :-(. I hope this fixed it. In any case, for some reason the segfault always happened in the operator= method of QString. I hope this bug is never reopened!