attica_kde.so closing crash

[Thomas Lübking]

On Montag, 17. November 2014 00:38:03 CEST, Albert Astals Cid wrote:

> El Dilluns, 17 de novembre de 2014, a les 00:33:17, Thomas Lübking va 
> escriure:
>> You do not happen to delete a bechilded member in the 
>> destructor explicitly,
>> are you?

> Why would this be wrong?

"Nothing"*

*in general, but:

bool QCoreApplication::notify() {
// no events are delivered after ~QCoreApplication() has started
if (QCoreApplicationPrivate::is_app_closing)
    return true;
...
}

Since deleting children in the deconstructor is completely pointless and I /have/ seen things go south (style ...plugin!), so my rule of thumb is to leave moc alone and do not delete child members in destructors.

(Also since in addition, the glib dispatcher apparently has a tendency to defer events by one cycle)

I don't say "this is it!", but, quelle surprise:

QNetworkAccessManager::~QNetworkAccessManager()
{
#ifndef QT_NO_NETWORKPROXY
    delete d_func()->proxyFactory;
#endif

    // Delete the QNetworkReply children first.
    // Else a QAbstractNetworkCache might get deleted in ~QObject
    // before a QNetworkReply that accesses the QAbstractNetworkCache
    // object in its destructor.
    qDeleteAll(findChildren<QNetworkReply *>());
    // The other children will be deleted in this ~QObject
    // FIXME instead of this "hack" make the QNetworkReplyImpl
    // properly watch the cache deletion, e.g. via a QWeakPointer.
}

Jeremy, my wild shot in the dark would be to find all QNetworkReply children of m_accessManager, list them, check if there are some ;-), reparent them (to "0") and delete them in the deconstructor. If that "fixes" it, maybe this needs to be moved into the KIO AccessManager (as a temp workaround Qt)

Cheers,
Thomas