Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
5.0.2, 5.2.1
-
None
-
Debian 7 x64 gcc + Qt 5.0.2 or 5.2.1, multiple test machines. Does not occur under windows 8 x64 msvc + Qt 5.2 beta.
Description
It appears that there is a race condition in QNetworkReply that causes deleting the reply to crash.
See this testcase: https://bitbucket.org/sdessens/qnetworkreply-access-violation-testcase/overview
CrashServer is an application that sets up a simple HTTP TCP server on port 9999. CrashClient is an application that connects to that web server and disposes any network replies using the deleteLater slot. When given enough time, (about a day) the client crashes with the following valgrind output:
==18792== Invalid read of size 8 ==18792== at 0x53AAC7A: QObject::~QObject() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x4EB60A8: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Network.so.5.0.2) ==18792== by 0x53A4357: QObject::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x537EBBC: QCoreApplication::notify(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x537E8BD: QCoreApplication::notifyInternal(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x5380AC5: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x53C38D4: QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x537D88A: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x51F422A: QThread::exec() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x51F8A4A: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x5812B4F: start_thread (pthread_create.c:304) ==18792== by 0x62A1A7C: clone (clone.S:112) ==18792== Address 0xb9fd670 is 0 bytes inside a block of size 16 free'd ==18792== at 0x4C279DC: operator delete(void*) (vg_replace_malloc.c:457) ==18792== by 0x53A4357: QObject::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x537EBBC: QCoreApplication::notify(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x537E8BD: QCoreApplication::notifyInternal(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x5380AC5: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x53C38D4: QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x537D88A: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x538115F: QCoreApplication::exec() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.0.2) ==18792== by 0x4093C4: main (main.cpp:38)
The testcase does not crash (or at least, has much lower chance of crashing since i have never seen it happen) when the network reply is not destroyed using
reply->deleteLater()
but using
QTimer::singleShot( 1000, reply, SLOT(deleteLater()));
This leads me to believe that this crash is caused by modifying some internal QNetworkReply state after the finished() signal is emitted.
Attachments
Issue Links
- relates to
-
-
- Closed
-