Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection

2017-12-05 Thread Thiago Macieira 
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

2017-12-05 Thread René J . V . Bertin 
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

2017-12-05 Thread Thiago Macieira 
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

2017-12-05 Thread René J . V . Bertin 
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

2017-12-05 Thread Thiago Macieira 
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

2017-12-05 Thread René J . V . Bertin 
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

2017-12-05 Thread René J . V . Bertin 
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

2017-12-05 Thread Thiago Macieira 
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

2017-12-05 Thread René J . V . Bertin 
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=,

Re: [Development] QtCS 2017 QtCore sessions

2017-12-05 Thread Marc Mutz 

On 2017-12-04 21:05, Ville Voutilainen wrote:

Same goes for semantics.


In fact, I'm _mainly_ concerned with semantics. Different method naming 
is trivially fixed by tooling these days, as long as the semantics are 
the same.


As a trivial example: qAsConst, like std::as_const, has the rvalue 
overload `= delete`d. For Qt containers, and most STL ones, too, with 
the notable exceptions of QVLA and std::array, it would make sense to 
allow the rvalue overload, but return a new object moved from the 
original. Then lifetime extension would kick in and


  for (auto  : qAsConst(funReturningQVector()))

would be safe, albeit less efficient as the alternative. But getting rid 
of qAsConst would then be much harder, since std::as_const does not have 
an overload for rvalues, so the above code would need to be transformed 
into


  const auto uniq = funReturningQVector();
  for (auto  : uniq)

which is what you're forced to write today already, thanks to the lack 
of the rvalue overload.


As an aside: it also makes the API easier to abuse (by allowing 
std::array and QVLA rvalues).


So, IMNSHO, it's better to not add the rvalue overload to qAsConst, but 
keep it `= delete`d, thereby maintaining semantic one-to-one-ness with 
std::as_const, in turn making tools to perform the rewrite trivial (in 
this case, as easy as `s/qAsConst/std::as_const/g`).


Thanks,
Marc

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development