https://bugs.kde.org/show_bug.cgi?id=363753
--- Comment #30 from RJVB <rjvber...@gmail.com> --- In the meantime I think we should be realist and accept the fact that whatever bug there is in Qt it's not going to be fixed anytime soon. If we want people and distributions to consider QtCurve we'll have to implement a workaround. For me the Debian patch is as good an approach to that as any: it simplifies things (m_dbusConnected becomes a boolean and not a pointer to a cleanup handler which may remain NULL when registering fails; leave certain things to low-level dtors instead of doing them explicitly, ...). The alternative could be to cache `QDBusConnection::sessionBus()` and check whether it's connected; done right that should avoid calling a stale QDbusConnection instance through QDBusConnection::sessionBus()). Intuitively I'd say that should make sense; what's the point in (re)opening a session bus connection if you're about to disconnect from the D-Bus anyway and maybe were never connected to it? I can confirm that the Debian patch prevents the crash on Linux and Mac with all Qt versions I've tried; the KaOS maintainer also uses it in his packaging. I think the least we could do is maintain a branch with this patch in place. Which doesn't prevent us from filing a(nother) Qt bug report with a fresh backtrace, of course. But FWIW, from the QDbusConnection doc (5.8.0): "he sessionBus() and systemBus() functions return open connections to the session server daemon and the system server daemon, respectively. Those connections are opened when first used and are closed when the QCoreApplication destructor is run." That means that it's probably a good idea not to call those functions in code that is or can be run *after* the QCoreApplication dtor ... and that we should disconnect from the DBus before, like in a slot connected to QCoreApplication::QCoreApplication::aboutToQuit(). -- You are receiving this mail because: You are watching all bug changes.
