PDA

View Full Version : QTcpSocket crashes on read



xenome
7th May 2011, 17:51
Hi,

I'm not sure if this is a QT bug or something of my own doing, but the qbytearray that acts as the receive buffer for QTcpSocket crashes while performing a memcpy (called by resize)

The only socket read I perform is in the following slot code:
void DataFeed::readData(void)

{ //cout << "Reading data from device in slot..." << endl; QByteArray *pData = new QByteArray; *pData = mp_socket->readAll(); emit postData(pData); }
Here is my connection to the slot:

connect(mp_socket, SIGNAL(readyRead()), this, SLOT(readData()));

Here is my stack trace, from what I can tell the error is not generated because of my code or is related to the QByteArray I create on the heap.
0 memcpy /lib/x86_64-linux-gnu/libc.so.6 0 0x00007ffff66a6abb
1 QByteArray::realloc qbytearray.cpp 1424 0x00007ffff73fd56b
2 QByteArray::resize qbytearray.cpp 1389 0x00007ffff73fd9a9
3 QRingBuffer::reserve qringbuffer_p.h 158 0x00007ffff791e6df
4 QAbstractSocketPrivate::readFromSocket qabstractsocket.cpp 1158 0x00007ffff791912f
5 QAbstractSocketPrivate::canReadNotification qabstractsocket.cpp 614 0x00007ffff79194f5
6 QReadNotifier::event qnativesocketengine.cpp 1103 0x00007ffff7908791
7 QCoreApplicationPrivate::notify_helper qcoreapplication.cpp 867 0x00007ffff75024cf
8 QCoreApplication::notify qcoreapplication.cpp 813 0x00007ffff750254e
9 QCoreApplication::notifyInternal qcoreapplication.cpp 732 0x00007ffff75020a4
10 sendEvent qcoreapplication.h 215 0x00007ffff752fa3a
11 socketNotifierSourceDispatch qeventdispatcher_glib.cpp 110 0x00007ffff752fa3a
12 g_main_context_dispatch /lib/x86_64-linux-gnu/libglib-2.0.so.0 0 0x00007ffff5d5ebcd
13 ?? /lib/x86_64-linux-gnu/libglib-2.0.so.0 0 0x00007ffff5d5f3a8
14 g_main_context_iteration /lib/x86_64-linux-gnu/libglib-2.0.so.0 0 0x00007ffff5d5f639
15 QEventDispatcherGlib::processEvents qeventdispatcher_glib.cpp 415 0x00007ffff752fbcc
16 QEventLoop::processEvents qeventloop.cpp 149 0x00007ffff75013f5
17 QEventLoop::exec qeventloop.cpp 201 0x00007ffff7501646
18 QThread::exec qthread.cpp 490 0x00007ffff73f8014
19 DataFeed::run datafeed.cpp 103 0x000000000040c477
20 QThreadPrivate::start qthread_unix.cpp 266 0x00007ffff73faf5f
21 start_thread /lib/x86_64-linux-gnu/libpthread.so.0 0 0x00007ffff7157d8c
22 clone /lib/x86_64-linux-gnu/libc.so.6 0 0x00007ffff670204d
23 ?? 0 0x0000000000000000

squidge
7th May 2011, 18:30
Why all the complexity? What wrong with just "postData(mp_socket->readAll());" ? All you are doing is creating memory leaks...

xenome
7th May 2011, 20:02
I was trying to avoid the deep copy that would be necessary for a possible queued connection, but I agree with your point. In my defense, I do track the pointer and reclaim the memory...which I originally thought was related to the problem. The trace does not make me believe that though.

Any ideas on the problem?

Thanks

xenome
8th May 2011, 00:12
Just for kicks I changed the slot to your recommendation and I still get the exact same crash.

squidge
8th May 2011, 11:12
Are you sure that mp_socket is a valid pointer at all times? Add an assert to ensure.

wysota
8th May 2011, 11:18
Are you using threads?

xenome
8th May 2011, 12:12
Are you using threads?

Yes I am, am I doing something wrong?

wysota
8th May 2011, 12:52
Yes I am, am I doing something wrong?

Possibly. How do you use them?

xenome
8th May 2011, 13:26
I have my network interface thread that created the socket and posts the data as shown in the above slot code. I also have a message parser thread which takes in this QByteArray from the signal and adds the data to its internal buffer for parsing. This thread spins in an infinite loop reading tokens from this buffer (semaphore protected) and once it recognizes a complete message, it posts a new message (msg ptr to new message on the heap), this gets caught by another slot which adds the message (msg ptr) to a thread safe queue. The address of the queue is then sent to another thread for processing, once processing is complete the msg ptr is deleted.

Sounds a lot more complicated than it really is.

wysota
8th May 2011, 23:25
What do you need all those threads for? Sounds like one thread would just be enough to do the same task (and probably without crashing your application).