Details
-
Bug
-
Resolution: Done
-
P1: Critical
-
None
-
5.1.1
-
None
-
Reproduced on Qt 5.1.1 Linux 32 and 64 bits
Description
When calling deleteLater() on QNetworkReply in requestFinish() slot after an HTTP request, the process will crash with such a stack trace once out of a few thousands times:
(gdb) where #0 0x004f2027 in QObjectData::dynamicMetaObject (this=0xb246c9a0) at kernel/qobject.cpp:189 #1 0x00d3a195 in QNetworkReplyHttpImpl::metaObject (this=0x21011d88) at .moc/debug-shared/moc_qnetworkreplyhttpimpl_p.cpp:333 #2 0x004f37ee in QObject::~QObject (this=0x21024cc8, __in_chrg=<value optimized out>) at kernel/qobject.cpp:852 #3 0x004089a7 in QNonContiguousByteDevice::~QNonContiguousByteDevice (this=0x21024cc8, __in_chrg=<value optimized out>) at io/qnoncontiguousbytedevice.cpp:148 #4 0x00d3bb84 in QNonContiguousByteDeviceThreadForwardImpl::~QNonContiguousByteDeviceThreadForwardImpl (this=0x21024cc8, __in_chrg=<value optimized out>) at .moc/debug-shared/../../access/qhttpthreaddelegate_p.h:209 #5 0x00d3bbbb in QNonContiguousByteDeviceThreadForwardImpl::~QNonContiguousByteDeviceThreadForwardImpl (this=0x21024cc8, __in_chrg=<value optimized out>) at .moc/debug-shared/../../access/qhttpthreaddelegate_p.h:209 #6 0x004f4fed in QObjectPrivate::deleteChildren (this=0x210059b8) at kernel/qobject.cpp:1764 #7 0x004f3871 in QObject::~QObject (this=0x21037d40, __in_chrg=<value optimized out>) at kernel/qobject.cpp:857 #8 0x00cc8cc2 in QHttpThreadDelegate::~QHttpThreadDelegate (this=0x21037d40, __in_chrg=<value optimized out>) at access/qhttpthreaddelegate.cpp:190 #9 0x00cc8cfb in QHttpThreadDelegate::~QHttpThreadDelegate (this=0x21037d40, __in_chrg=<value optimized out>) at access/qhttpthreaddelegate.cpp:190 #10 0x004fb80c in qDeleteInEventHandler (o=0x21037d40) at kernel/qobject.cpp:4158 #11 0x004f3b16 in QObject::event (this=0x21037d40, e=0x318c4b18) at kernel/qobject.cpp:1061 #12 0x004bdb9d in QCoreApplicationPrivate::notify_helper (this=0x98785c8, receiver=0x21037d40, event=0x318c4b18) at kernel/qcoreapplication.cpp:984 #13 0x004bd897 in QCoreApplication::notify (this=0xbfd15af4, receiver=0x21037d40, event=0x318c4b18) at kernel/qcoreapplication.cpp:929 #14 0x004bd7a1 in QCoreApplication::notifyInternal (this=0xbfd15af4, receiver=0x21037d40, event=0x318c4b18) at kernel/qcoreapplication.cpp:867 #15 0x004c129d in QCoreApplication::sendEvent (receiver=0x21037d40, event=0x318c4b18) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:232 #16 0x004be915 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0xb24efb50) at kernel/qcoreapplication.cpp:1471 #17 0x004be3d7 in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1329 #18 0x0052728f in postEventSourceDispatch (s=0x28a54d70) at kernel/qeventdispatcher_glib.cpp:279 #19 0x03fc4525 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #20 0x03fc8268 in ?? () from /lib/libglib-2.0.so.0 #21 0x03fc8449 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #22 0x00527a08 in QEventDispatcherGlib::processEvents (this=0x506aef48, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #23 0x004ba2a1 in QEventLoop::processEvents (this=0x1abf5248, flags=...) at kernel/qeventloop.cpp:136 #24 0x004ba569 in QEventLoop::exec (this=0x1abf5248, flags=...) at kernel/qeventloop.cpp:212 #25 0x002da361 in QThread::exec (this=0xb24edd50) at thread/qthread.cpp:507 #26 0x002da4f7 in QThread::run (this=0xb24edd50) at thread/qthread.cpp:574 #27 0x002e0953 in QThreadPrivate::start (arg=0xb24edd50) at thread/qthread_unix.cpp:345 #28 0x001a2919 in start_thread () from /lib/libpthread.so.0 #29 0x0090ad4e in clone () from /lib/libc.so.6 (gdb) quit
This can be reproduced with a sample program of mine which can be found here https://github.com/g76r/test_qt_network.git or attached to this bug report.
The crash can take a while to happen, I cannot say exactly how much and it probably depends on the computer, but each time I started it in the evening the crashed occured before I wake up in the morning.
The same occur if Example, QNetworkAccessManager and QNetworkReply belong to main thread or are moved to a separate one. The same occur with get, post and push methods.
This do not occur with Qt 4.8.5.
I read QNetworkReply source code and could not find out the origin of the bug.
Attachments
Issue Links
- resulted in
-
QTBUG-133213 Data race due to disconnectNotify (e.g. in QNetworkAccessManager, QHostInfoResult, etc.)
-
- Reported
-
For Gerrit Dashboard: QTBUG-34131 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
71963,2 | Fix race condition between destruction of QObjects | release | qt/qtbase | Status: MERGED | +2 | 0 |