<div dir="ltr">Thomas,<div><br></div><div>Thanks for the pointer. I tried changing KIO::AccessManager's destructor to this:</div><div><br></div><div><div>AccessManager::~AccessManager()</div><div>{</div><div>    QObjectList childList = children();</div><div>    Q_FOREACH(QObject *child, childList) {</div><div>        QNetworkReply *reply = qobject_cast<QNetworkReply*>(child);</div><div>        if (reply != 0) {</div><div>            qDebug() << "Setting reply parent to null";</div><div>            reply->setParent(0);</div><div>            qDebug() << "deleting reply object";</div><div>            delete reply;</div><div>        } else {</div><div>            qDebug() << "child " << child << " isn't a networkreply"</div><div>                     << "it is a " << child->metaObject()->className();</div><div>        }</div><div>    }</div><div>    delete d;</div><div>}</div><div><br></div></div><div>and got this output before the crash:</div><div><br></div><div><div>[Thread 0x7fffd3fff700 (LWP 17285) exited]</div><div>[Thread 0x7fffe7128700 (LWP 17279) exited]</div><div>child  KIO::Integration::CookieJar(0xa2dc50)  isn't a networkreply it is a  KIO::Integration::CookieJar</div><div><br></div><div>Program received signal SIGSEGV, Segmentation fault.</div><div>0x00007ffff720057e in QExplicitlySharedDataPointer<QNetworkConfigurationPrivate>::~QExplicitlySharedDataPointer (this=0xa14d30, __in_chrg=<optimized out>)</div><div>    at ../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qshareddata.h:156</div><div>156         inline ~QExplicitlySharedDataPointer() { if (d && !d->ref.deref()) delete d; }</div></div><div><br></div><div>So unless the cookiejar is making QNetworkAccessManager's destructor fail I don't see how this could be a solution for the problem unfortunately.</div><div><br></div><div>thanks,</div><div>Jeremy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 17, 2014 at 6:50 AM, Thomas Lübking <span dir="ltr"><<a href="mailto:thomas.luebking@gmail.com" target="_blank">thomas.luebking@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Montag, 17. November 2014 00:38:03 CEST, Albert Astals Cid wrote:<br>
<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
El Dilluns, 17 de novembre de 2014, a les 00:33:17, Thomas Lübking va escriure:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You do not happen to delete a bechilded member in the destructor explicitly,<br>
are you?<br>
</blockquote></blockquote>
<br><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why would this be wrong?<br>
</blockquote>
<br></span>
"Nothing"*<br>
<br>
*in general, but:<br>
<br>
bool QCoreApplication::notify() {<br>
// no events are delivered after ~QCoreApplication() has started<br>
if (QCoreApplicationPrivate::is_<u></u>app_closing)<br>
   return true;<br>
...<br>
}<br>
<br>
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.<br>
<br>
(Also since in addition, the glib dispatcher apparently has a tendency to defer events by one cycle)<br>
<br>
I don't say "this is it!", but, quelle surprise:<br>
<br>
QNetworkAccessManager::~<u></u>QNetworkAccessManager()<br>
{<br>
#ifndef QT_NO_NETWORKPROXY<br>
   delete d_func()->proxyFactory;<br>
#endif<br>
<br>
   // Delete the QNetworkReply children first.<br>
   // Else a QAbstractNetworkCache might get deleted in ~QObject<br>
   // before a QNetworkReply that accesses the QAbstractNetworkCache<br>
   // object in its destructor.<br>
   qDeleteAll(findChildren<<u></u>QNetworkReply *>());<br>
   // The other children will be deleted in this ~QObject<br>
   // FIXME instead of this "hack" make the QNetworkReplyImpl<br>
   // properly watch the cache deletion, e.g. via a QWeakPointer.<br>
}<br>
<br>
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)<br>
<br>
Cheers,<br>
Thomas<br>
</blockquote></div><br></div>