[Interest] QNetwork problem in threaded application (repost from development).

Benjamin Zeller zeller.benjamin at web.de
Tue Sep 10 17:29:19 CEST 2013


I did some more debugging today, something changed but its still
crashing at the same place:

- The QAbstractSocket now has a QAdoptedThread affinity
- The QAbstractSocket has a 0x0 pointer to the engine
- The QAbstractSocketEngine has a WorkerThread affinity
- The QAbstractSocketEngine has no parent (0x0)
- The QReadNotifier has a WorkerThread affinity

Isn't it weird that i still can read valid data from the this
pointer when i'm in a QAbstractSocketEngine:: member func,
event if its a 0 pointer in the QAbstractSocket?

i tried to put a thread test in
void QAbstractSocketPrivate::resetSocketLayer()
with no luck, seems the correct thread is the first one here.

If you have any other idea where i can put in some testcode
let me know and i will try. I have a extra qt compiled for
development and can put in testcode easily.

Here you can see what i pointed out, different thread
affinities and broken parentship (i assume QAbstractSocketEngine
should have a parent):

this pointer when i'm in frame #3

this  QTcpSocketPrivate
   [QAbstractSocketPrivate]    QAbstractSocketPrivate
     [QIODevicePrivate]    QIODevicePrivate
       [QObjectPrivate]    QObjectPrivate
         [QObjectData]    QObjectData
           q_ptr    QTcpSocket
             [QAbstractSocket]    QAbstractSocket
               [QIODevice]    QIODevice
                 [QObject]    QObject
                   children  <0 items>  QObjectList
                   connections  <>0 items>
                   currentSender  0x0
                   parent    Tufao::HttpServerRequest
           receiveChildEvents  1  uint
           sendChildEvents  1  uint
           unused  0  uint
           wasDeleted  0  uint
         threadData    QThreadData
           _ref  4115  QAtomicInt
           canWait  false  bool
           eventDispatcher  <not accessible>
           eventLoops  <1 items>  QStack<QEventLoop*>
           isAdopted  true  bool
           loopLevel  2  int
           postEventList    QPostEventList
           quitNow  false  bool
           thread    QAdoptedThread
           threadId  0x7fbe90a78740  Qt::HANDLE
           tls  <0 items>  QVector<void*>
       accessMode  QIODevicePrivate::Sequential (1)
       baseReadLineDataCalled  false  bool
       buffer    QIODevicePrivateLinearBuffer
       devicePos  0  qint64
       errorString  "Socket is not connected"  QString
       firstRead  false  bool
       openMode  QIODevice::ReadWrite (3)  QIODevice::OpenMode
       pDevicePos  0  qint64
       pPos  0  qint64
       pos  76  qint64
       seqDumpPos  0  qint64
     socketEngine  0x0  QAbstractSocketEngine *
     socketError  QAbstractSocket::UnknownSocketError (-1)
     socketType  QAbstractSocket::TcpSocket (0)
     state  QAbstractSocket::UnconnectedState (0)
     writeBuffer    QRingBuffer

this->q_ptr when i'm in frame #5
(QObjectPrivate*)d_ptr    QObjectPrivate
   [QObjectData]    QObjectData
     [vptr]  0x2723ce0
     blockSig  0  uint
     children  <not accessible>  QList<QObject*>
     isDeletingChildren  0  uint
     isWidget  0  uint
     isWindow  0  uint
     metaObject  0x0  QDynamicMetaObjectData *
     parent  0x0  QObject *
     postedEvents  0  int
     q_ptr  <not accessible>
     receiveChildEvents  1  uint
     sendChildEvents  1  uint
     unused  303207  uint
     wasDeleted  1  uint
   connectedSignals  @0x2503878  unsigned int [2]
   connectionLists  0x0  QObjectConnectionListVector *
   currentChildBeingDeleted  0x0  QObject *
   currentSender  0x0  QObjectPrivate::Sender *
   declarativeData  0x0  QAbstractDeclarativeData *
   extraData    QObjectPrivate::ExtraData
   senders  0x0  QObjectPrivate::Connection *
   sharedRefcount  <not accessible>
   threadData    QThreadData
     _ref  9  QAtomicInt
     canWait  false  bool
     eventDispatcher  <not accessible>
     eventLoops  <0 items>  QStack<QEventLoop*>
     isAdopted  false  bool
     loopLevel  0  int
     postEventList    QPostEventList
     quitNow  false  bool
     thread    Tufao::WorkerThread
       [QThread]    QThread
       cleanup    std::function<void(void**)>
       dispatcher    Tufao::ThreadedHttpRequestDispatcher::Priv
       factory
       id  49  int
       m_wait    QWaitCondition
       mutex    QMutex
       myRequest    Tufao::WorkerThread::Request
       shutdownRequested  false  bool
       staticMetaObject    QMetaObject
     threadId  0x7fbe357ea700  Qt::HANDLE
     tls  <0 items>  QVector<void*>


backtrace:
0	QCoreApplication::instance	qcoreapplication.h	115	0x7fbe903103d1	
1	<function called from gdb>			0x7ffff41a925f	
2	typeinfo name for QObjectPrivate	/opt/Qt/5.1.1/lib/libQt5Core.so.5	 
0x7fbe8ff1e050	
3	QAbstractSocketPrivate::canReadNotification	qabstractsocket.cpp	745 
0x7fbe90338f5d	
4	QAbstractSocketPrivate::readNotification	qabstractsocket_p.h	77 
0x7fbe9033ee90	
5	QAbstractSocketEngine::readNotification	qabstractsocketengine.cpp 
156	0x7fbe9032acb9	
6	QReadNotifier::event	qnativesocketengine.cpp	1147	0x7fbe903472c0	
7	QCoreApplicationPrivate::notify_helper	qcoreapplication.cpp	984 
0x7fbe8fda618c	
8	QCoreApplication::notify	qcoreapplication.cpp	929	0x7fbe8fda5e4e	
9	QCoreApplication::notifyInternal	qcoreapplication.cpp	867	0x7fbe8fda5d56	
10	QCoreApplication::sendEvent	qcoreapplication.h	232	0x7fbe8fda98bb	
11	socketNotifierSourceDispatch	qeventdispatcher_glib.cpp	109 
0x7fbe8fe154b0	
12	g_main_context_dispatch	/usr/lib/libglib-2.0.so.0		0x7fbe8da88d96	
13	??	/usr/lib/libglib-2.0.so.0		0x7fbe8da890e8	
14	g_main_context_iteration	/usr/lib/libglib-2.0.so.0		0x7fbe8da8918c	
15	QEventDispatcherGlib::processEvents	qeventdispatcher_glib.cpp	426 
0x7fbe8fe16163	
16	QEventLoop::processEvents	qeventloop.cpp	136	0x7fbe8fda2ab6	
17	QEventLoop::exec	qeventloop.cpp	212	0x7fbe8fda2d99	
18	QCoreApplication::exec	qcoreapplication.cpp	1120	0x7fbe8fda6432	
19	main	main.cpp	85	0x4036a4		


Btw, what would happen if the thread does not enter a eventloop but
instead handle the socket in a blocking mode, then pushes it back to
the mainthread? Would the move be correct?
I think QSocketNotifier uses a posted event to reenable itself after
a move... which means this is not delivered properly


On 09.09.2013 23:07, Thiago Macieira wrote:
> On segunda-feira, 9 de setembro de 2013 21:46:56, Benjamin Zeller wrote:
>> Is it maybe possible that due to high load the ThreadChange Event gets
>> lost (or is delivered too late)? The socket descriptor is then never
>> disabled and reenabled , which means the thread affinity would be wrong.
>
> The ThreadChange event is sent synchronously with sendEvent, which causes
> QSocketNotifier to synchronously unregister itself. It can't get lost due to
> high load.
>
> But like I asked you on IRC: it may get lost if an event filter discards it.
>
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>




More information about the Interest mailing list