Problems with network connection, signals and threads

django.Reinhard

I have developed a network connection with unittests and in the test everything works as expected.

Now I put the connection part in the application and there I get problems. It took a while until all event-callbacks were executed in the right thread. Because of the fragmentation of the network transfer by the different signals I store the message in a private member variable. Then in the corresponding callback the member variable is read and sent.

My problem is that the content of the member variable changes between event callbacks. For this I have set data breakpoints on the variable to find out who is poaching in memory.
At startup, the data breakpoint hits once at an unexpected place:
Thread QDBusConnection, Stack QDBusConnectionTypeInfo -> QByteArray

This is before the variable is even created. The variable is a pointer that is set to 0 in the constructor. Then the first time a message is sent, a QByteArray is created on the pointer and filled with data.
Then a connection is established with a QTcpSocket (connectToHost). At OnConnected-callback the message should be sent, but now the QByteArray already has a different content.

I checked if the class is the same instance and if everything happens in the right thread. Then I checked if maybe the destructor is called. None of this is true. There is also no friend declaration that a stranger could use to change the private variable ...

Now I'm at a loss. How can I find out who is screwing up my memory space and why?

SGaist

Hi,

Anything "static" in your design ?

django.Reinhard

Hi and thank you for your attention.

No static was not the problem.
But triggered by your question, I found it.

I built a blocking socket variant and then on debugging I saw, that the message body was clobbered at socket.connectToHost ...

I treated that possiblity as impossible and started a wider search, which leaded to my fault:
I used QByteArray::setRawData() and thought, that would copy the source buffer. But that's not true (RTFM). I had to use the constructor with buffer-pointer and buffer size to obtain a deep buffer copy.

Now it works.