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.luebk...@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
>
