Bug 216021

Seems to be a kdelibs-related issue.

*** Bug 206181 has been marked as a duplicate of this bug. ***

From bug 224915:
-- Information about the crash:
I had my laptop in standby. I returned, and the networkmanager had connected me
to the wrong WLAN (which needs activated VPN to work). So I changed it to the
other one. At this point Kopete crashed.

*** Bug 224915 has been marked as a duplicate of this bug. ***

Created attachment 49940 [details]
New crash information added by DrKonqi

kopete (1.0.80) on KDE Platform 4.4.92 (KDE 4.4.92 (KDE 4.5 RC2)) using Qt 4.7.0

- What I was doing when the application crashed:

Network cable was pulled accidently, Kopete crashed.  Used protocols: Jabber and Bonjour.

-- Backtrace (Reduced):
#7  0x06aeb179 in QList<KSharedPtr<DNSSD::RemoteService> >::removeAll(KSharedPtr<DNSSD::RemoteService> const&) () from /usr/lib/libkdnssd.so.4
#8  0x06ae8d4d in DNSSD::ServiceBrowserPrivate::gotRemoveService (this=0xa3f3cf0, name=..., type=..., domain=...) at ../../dnssd/avahi-servicebrowser.cpp:137
#9  0x06ae8e56 in DNSSD::ServiceBrowserPrivate::qt_metacall (this=0xa3f3cf0, _c=QMetaObject::InvokeMetaMethod, _id=8, _a=0xbfbab804) at ./avahi-servicebrowser_p.moc:84
[...]
[...]
#12 0x06afb6ab in OrgFreedesktopAvahiServiceBrowserInterface::ItemRemove (this=0xa3bc840, _t1=2, _t2=0, _t3=..., _t4=..., _t5=..., _t6=4) at avahi_servicebrowser_interface.moc:129
#13 0x06afb9ee in OrgFreedesktopAvahiServiceBrowserInterface::qt_metacall (this=0xa3bc840, _c=QMetaObject::InvokeMetaMethod, _id=4, _a=0xbfbab99c) at avahi_servicebrowser_interface.moc:89

*** Bug 252285 has been marked as a duplicate of this bug. ***

This seems to be a problem with DNSSD::ServiceBrowserPrivate::gotRemoveService code. It emits a signal and then proceeds to delete some element of the m_services QList:

     emit m_parent->serviceRemoved(found);
     m_services.removeAll(found);

What happens in Kopete, and particularly its Bonjour code, is that from that signal, Kopete goes offline and deletes the ServiceBrowser instance. The control then returns to gotRemovalService, which tries to do the deletion an a freed object.

The best solution is probably to postpone the deletion of found to the main loop with QTimer::singleShot, because that can be made so deletion of the ServiceBrowser object automatically cancels its execution. (I've got a patch for it, tested and seems to work.) However, I wonder whether in essence all code that emits signals shouldn't be treated that way, since you don't really know what happens when the slot connected to the signal executes.

I've also considered if Kopete couldn't be changed so as not to delete the ServiceBrowser, however, I haven't found a way.

1. Stopping the ServiceBrowser without actually deleting it (and then maybe restarting it) could work, but I can't see how you could do it.

2. Postponing the deletion to the main loop via ->deleteLater doesn't work, because it just so happens that the main loop can be nested in kopete. The call stack looks like this:

(BonjourAccount::disconnect would be called here)
0xaffd45dd in DNSSD::ServiceBrowserPrivate::gotRemoveService (this=0x21ace40, name=..., type=..., domain=...) at ./dnssd/avahi-servicebrowser.cpp:137
...
0xaffd8a05 in DNSSD::RemoteService::resolve (this=0x21a9e00) at ./dnssd/avahi-remoteservice.cpp:49
0xb006fefe in BonjourAccount::goingOffline (this=0x207abe0, pointer=...) at ./protocols/bonjour/bonjouraccount.cpp:273
...
0xaffd3e01 in DNSSD::ServiceBrowser::serviceRemoved (this=0x21133f0, _t1=...) at ./obj-i686-linux-gnu/dnssd/servicebrowser.moc:111
0xaffd45c9 in DNSSD::ServiceBrowserPrivate::gotRemoveService (this=0x21ace40, name=..., type=..., domain=...) at ./dnssd/avahi-servicebrowser.cpp:136

DNSSD::RemoteService::resolve contains an event loop, which means the deferred deletion would be effective by the time control returns there. The gotRemoveService sitting up above it in the stack, would be doomed. (Also tested.) Of course this nested event loop is bad design, but what can you do?

Created attachment 111955 [details]
Full backtrace showing the nested event loop problem

Thank you for the crash report.

As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved.

I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!