Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection
I've decided to file this as a bug at least for future reference: https://bugreports.qt.io/browse/QTBUG-64996 I tried my luck with valgrind but apparently that modifies the runtime environment sufficiently to avoid the crash. If there was a useful hint in the valgrind output it got lost in tons of supposed errors esp. in libcrypto (probably uninitialised variable false alarms). R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection
On Tuesday, 5 December 2017 13:36:09 PST René J.V. Bertin wrote: > On Tuesday December 05 2017 11:11:12 Thiago Macieira wrote: > > Ok, the only differences between 5.9 and 5.10 are replacing 0 with nullptr > > and removing one no-op. > > Has anything changed in the handling of style plugins between 5.8 and 5.9? > > A few more lines of output later I now know that the stale sender object > corresponds to the style instance which is delete'd (much) earlier than the > call to QDbusConnectionPrivate::closeConnection() in the global > destruction. > > Yet we call `disconnect()` in the style dtor. > > I'm a bit at a loss understanding why this would bite us only in very select > applications. The only sensible explanation I see is that the app in > question here (rekonq) hasn't been maintained for a few years and may never > have been ported correctly to Qt5. disconnect() what? QDBusConnection has held locks on each registered object since Qt 4.3. The dying object cannot complete destruction until QDBusConnection has had a chance to operate. So no pointer to a QObject can become invalid before QDBusConnection disconnects the private. The specific code you're talking about did receive a patch for the exact cause you're talking about in commit ad66dbe305cff72443f4d3484191872d56e6dfbb, but that's 5.7.0. The issue was that some QObjects could be registered more than once with QDBusConnection, but QObject::disconnect() does not take a refcount, it disconnected all connections. At that point, the object was free to be deleted. The alternative I can think of is that object wasn't destroyed, but the library where the destructor code resides has been unloaded. That could explain the ?? and weird pointer address at the top of the stack. Can you see if this is the case? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection
On Tuesday December 05 2017 11:11:12 Thiago Macieira wrote: > Ok, the only differences between 5.9 and 5.10 are replacing 0 with nullptr > and > removing one no-op. Has anything changed in the handling of style plugins between 5.8 and 5.9? A few more lines of output later I now know that the stale sender object corresponds to the style instance which is delete'd (much) earlier than the call to QDbusConnectionPrivate::closeConnection() in the global destruction. Yet we call `disconnect()` in the style dtor. I'm a bit at a loss understanding why this would bite us only in very select applications. The only sensible explanation I see is that the app in question here (rekonq) hasn't been maintained for a few years and may never have been ported correctly to Qt5. R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection
On Tuesday, 5 December 2017 10:42:54 PST René J. V. Bertin wrote: > Thiago Macieira wrote: > > Please upgrade to 5.10 and apply the fixes again. But other than that, > > there are no known issues because there aren't many changes either. > > I don't think I'll be trying 5.10 any time soon, 5.9 is the newest version I > hope I'll be able to run across all my systems. Ok, the only differences between 5.9 and 5.10 are replacing 0 with nullptr and removing one no-op. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection
Thiago Macieira wrote: > Please upgrade to 5.10 and apply the fixes again. But other than that, there > are no known issues because there aren't many changes either. I don't think I'll be trying 5.10 any time soon, 5.9 is the newest version I hope I'll be able to run across all my systems. R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection
On Tuesday, 5 December 2017 08:23:05 PST René J. V. Bertin wrote: > Thiago Macieira wrote: > > Keep applying the patch on top of the official release. > > Wasn't that clear? I'm still running 5.8 *with* the fixes. No, it wasn't. Please upgrade to 5.10 and apply the fixes again. But other than that, there are no known issues because there aren't many changes either. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection
René J. V. Bertin wrote: > It appears to be an issue caused by (with?) the QtCurve widget style, though. One that goes away when I add an output tracer just before exiting from the style's dtor ... =/ R ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection
Thiago Macieira wrote: > Keep applying the patch on top of the official release. Wasn't that clear? I'm still running 5.8 *with* the fixes. This does look like a related-but-different issue though, trying to disconnect a valid receiver from a sender instance which has apparently already been deleted. It appears to be an issue caused by (with?) the QtCurve widget style, though. FWIW, this is what I get for the receiver object: (lldb) p ((QObject*)receiver)->dumpObjectInfo() OBJECT QDBusConnectionPrivate::unnamed SIGNALS OUT signal: destroyed(QObject*) signal: destroyed() signal: objectNameChanged(QString) signal: dispatchStatusChanged() signal: spyHooksFinished(QDBusMessage) signal: messageNeedsSending(QDBusPendingCallPrivate*,void*,int) signal: messageNeedsSending(QDBusPendingCallPrivate*,void*) signal: signalNeedsConnecting(QString,QDBusConnectionPrivate::SignalHook) signal: signalNeedsDisconnecting(QString,QDBusConnectionPrivate::SignalHook) signal: serviceOwnerChanged(QString,QString,QString) signal: callWithCallbackFailed(QDBusError,QDBusMessage) SIGNALS IN <-- QDBusAdaptorConnector::unnamed relaySignal(QObject*,const QMetaObject*,int,QVariantList) <-- KHintsSettingsMac::unnamed <-- QDBusConnectionPrivate::unnamed <-- QDBusConnectionPrivate::unnamed <-- QDBusConnectionPrivate::unnamed <-- QDBusConnectionPrivate::unnamed <-- QDBusConnectionPrivate::unnamed ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection
On Tuesday, 5 December 2017 06:34:26 PST René J.V. Bertin wrote: > Is the crash below another (new?) variant of the on-exit QDBus crashes for > which a few fixes were pushed a couple months ago, a new bug I should > report, or is this the result of a bug in the dependent code? The fixes were reverted. So if you stopped using them, you brought them back. Keep applying the patch on top of the official release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
