attica_kde.so closing crash

[Jeremy Whiting]

Thomas,

Thanks for the pointer. I tried changing KIO::AccessManager's destructor to
this:

AccessManager::~AccessManager()
{
    QObjectList childList = children();
    Q_FOREACH(QObject *child, childList) {
        QNetworkReply *reply = qobject_cast<QNetworkReply*>(child);
        if (reply != 0) {
            qDebug() << "Setting reply parent to null";
            reply->setParent(0);
            qDebug() << "deleting reply object";
            delete reply;
        } else {
            qDebug() << "child " << child << " isn't a networkreply"
                     << "it is a " << child->metaObject()->className();
        }
    }
    delete d;
}

and got this output before the crash:

[Thread 0x7fffd3fff700 (LWP 17285) exited]
[Thread 0x7fffe7128700 (LWP 17279) exited]
child  KIO::Integration::CookieJar(0xa2dc50)  isn't a networkreply it is a
 KIO::Integration::CookieJar

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff720057e in
QExplicitlySharedDataPointer<QNetworkConfigurationPrivate>::~QExplicitlySharedDataPointer
(this=0xa14d30, __in_chrg=<optimized out>)
    at
../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qshareddata.h:156
156         inline ~QExplicitlySharedDataPointer() { if (d &&
!d->ref.deref()) delete d; }

So unless the cookiejar is making QNetworkAccessManager's destructor fail I
don't see how this could be a solution for the problem unfortunately.

thanks,
Jeremy

On Mon, Nov 17, 2014 at 6:50 AM, Thomas Lübking <thomas.luebking at gmail.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20141117/df061974/attachment.htm>