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

[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