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
[Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection
Hi, 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? rekonq built on Linux from the frameworks git head, Qt 5.8 (with the QDBus patches backported), KF5 frameworks @Konstatin Tokarev : this is with QtWebKit 5.212 Alpha2 - not that I think it's related. #6 0x01832c40 in ?? () #7 0x7f5c2985efd1 in QObject::disconnect (sender=0x907590, signal=signal@entry=0x0, receiver=receiver@entry=0x7f5c040030f0, method=method@entry=0x0) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qobject.cpp:2956 #8 0x7f5c2bbea770 in disconnect (member=0x0, receiver=0x7f5c040030f0, this=) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/include/QtCore/../../src/corelib/kernel/qobject.h:339 #9 QDBusConnectionPrivate::closeConnection (this=this@entry=0x7f5c040030f0) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusintegrator.cpp:1147 #10 0x7f5c2bbea994 in QDBusConnectionPrivate::~QDBusConnectionPrivate (this=0x7f5c040030f0, __in_chrg=) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusintegrator.cpp:1071 #11 0x7f5c2bbeaca9 in QDBusConnectionPrivate::~QDBusConnectionPrivate (this=0x7f5c040030f0, __in_chrg=) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusintegrator.cpp:1091 #12 0x7f5c2bbde0fe in QDBusConnectionManager::run (this=0x7f5c2be4e460 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusconnection.cpp:178 #13 0x7f5c29664cf9 in QThreadPrivate::start (arg=0x7f5c2be4e460 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368 #14 0x7f5c2878f184 in start_thread (arg=0x7f5c0a6d6700) at pthread_create.c:312 #15 0x7f5c28aa2ffd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7f5c32ad68c0 (LWP 18256)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f5c29665aeb in wait (time=18446744073709551615, this=0x90aba0) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:143 #2 QWaitCondition::wait (this=this@entry=0x90bee0, mutex=mutex@entry=0x90bec0, time=time@entry=18446744073709551615) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:215 #3 0x7f5c296648ee in QThread::wait (this=this@entry=0x7f5c2be4e460 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>, time=time@entry=18446744073709551615) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:698 #4 0x7f5c2bbdba96 in QDBusConnectionManager::~QDBusConnectionManager (this=0x7f5c2be4e460 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>, __in_chrg=) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusconnection.cpp:149 #5 0x7f5c2bbdbb59 in (anonymous namespace)::Q_QGS__q_manager::Holder::~Holder (this=, __in_chrg=) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusconnection.cpp:72 #6 0x7f5c2bbdbb59 in operator() (this=) from /opt/local/libexec/qt5/lib/libQt5DBus.so.5 #7 QDBusConnection::systemBus () at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusconnection.cpp:1186 #8 0x7f5c289e11a9 in __run_exit_handlers (status=0, listp=0x7f5c28d676c8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82 #9 0x7f5c289e11f5 in __GI_exit (status=) at exit.c:104 #10 0x7f5c289c6f4c in __libc_start_main (main=0x400b00, argc=1, argv=0x7ffed8743628, init=, fini=, rtld_fini=,