Qt/C++/Valgrind Invalid Readsize of 8 on QTcpSocket disconnect

Question

I'm running valgrind on my Qt/C++ program and am getting this error:

Invalid read of size 8
  in TelnetConnection::disconnectClient() in telnetserver/telnetconnection.cpp:188

and line 188 is the waitForDisconnected line below:

void TelnetConnection::disconnectClient()
{
    tcpSocketPtr->disconnectFromHost();
    tcpSocketPtr->waitForDisconnected();
}

I'm not completely sure what this error means, but how can I fix this? Or is this out of my control? (a Qt issue)?

I'm not sure it's related, but the only other error I'm getting is:

384 bytes in 1 blocks are possibly lost in loss record 5,342 of 5,972
  in TelnetServer::incomingConnection(long long) in telnetserver/telnetserver.cpp:22

and the error line is Start() below:

void TelnetServer::incomingConnection(qintptr socketDescriptor)
{
    TelnetConnection *thread = new TelnetConnection(socketDescriptor, this);
    connect(thread, SIGNAL(shutdownRequested()), m_controller, SLOT(shutdownCommandIssued()));
    connect(thread, SIGNAL(finished()), thread, SLOT(deleteLater()));
    connect(m_controller, SIGNAL(shutingdown()), thread, SLOT(shutdownConnection()));
    thread->start();
}

again...how can this start function cause a memory leak? Or do the words "possibly lost" mean it's actually ok?

I've not seen this error for ``->start()`` yet, but it looks as you did subclass QThread. Its not the prefered way most of the time. Eventually your subclassing has to do something with the second message. Actually it looks like valgrind is reducing the whole thread-subclass to ``thread->start()``. The words "possibly lost" means, you eventually got a leak. The first message just tells you your app did try to read from an invalid memory address. This eventually happens when ``waitforDisconnected()`` checks if the connection is still valid, but the connection memory has already been freeed. — Sebastian Lange, Oct 09 '13 at 06:03
To fix the first message, should I check isOpen on the socket first, and only if true call waitforDisconnected? (Or is there a 'right' wait to avoid this). I'm unclear what you mean 'do something with the second message'...how do I fix this? — TSG, Oct 09 '13 at 06:18
Subclassing QThread should only be done by a single linear long running instruction block (for example image processing). As soon as you need events/signals/slots, condition-waits, mutexes, loops etc. you are constrained to create an object and move this to a not-sublclassed QThread (use signal/slot connections) or use QtConcurrent. BUT this will probably not solve your (possible) leak, its just the good practice way working with threads. It is not said there has to be a leak, its just that valgrind cannot find information about the missing blocks. — Sebastian Lange, Oct 09 '13 at 06:33
I've narrowed the memory leak down to when I delete the QTcpSocket. Since it is created on the heap inside the QThread, I'm having trouble finding where to delete it (without causing a memory leak). Deletelater didn't work...if I could override the destructor for this QThread it would probably work great there. Ideas? — TSG, Oct 09 '13 at 20:19

score 0 · Accepted Answer · answered Oct 12 '13 at 13:31

See sebastian's comments above for the best answer. Basically the read/write error is due to continued traffic to the socket even after closing the socket (close does not stop all traffic). The solution is to delete the socket on deleting the thread.

Qt/C++/Valgrind Invalid Readsize of 8 on QTcpSocket disconnect

1 Answers1