PDA

View Full Version : Qbytearrays do not function with big arrays?



Pereubu2018
20th July 2018, 12:26
What is wrong with my code?

QbytesArray bufferFile;
QbytesArray buffer;
int receiveBytes, size;
…

receivedBytes += size;
bufferFile.resize(receivedBytes);
bufferFile.push_back(buffer.data()); \\ or bufferFile.push_back(buffer) which generates the same result

I am working with Qbytearray of around 100000 length. The reason why I have opted for qbytesArray is what I expect that I do not have
to allocate that big array of unsigned characters beforehand.


For some reason I tried to resize that qbytearray to accomodate some new data arrived from the socket.. Unfortunately on my debugger I have seen that
new characters are added (205 or 'Í') and even more the number of added characters is not what I expects...? It seems to me that nearly all data from
qt 5.11.0 - msvc 2017 c++ are gone.


What I doing wrong?

tuli
20th July 2018, 12:41
resize() changes the size of the QByteArray. If it is smaller than the new size, it will add uninitialized data (in your case seemingly 205 or 'Í') to it. PushBack also changes the size of the array.


Just remove the resize(...) call. (Maybe you confused resize() and reserve(). )

Pereubu2018
20th July 2018, 14:12
Ok. That is fine. But the question remains why do we need resize() in the first place.
The second I could not see that qbytearray works as expected:

receivedBytes += size;
bufferFile.push_back(buffer.data());
int ret = bufferFile.size();

Qbytearray::data() Returns a pointer to the data stored in the byte array. I expect that receivedBytes are same int as ret. It is not because some of data has been lost. That is the problem I stared with.

tuli
20th July 2018, 15:01
you dont need the resize call. delete it.

push_back(buffer.data()) calls the overload for char*, meaning it breaks if your data contains null-bytes.
You can call the overload for qbytearray directly:


QbytesArray bufferFile;
QbytesArray buffer;
int receiveBytes, size;
…

receivedBytes += size;
bufferFile.push_back(buffer);

Pereubu2018
23rd July 2018, 11:39
It is still not working as it was before. The problem is that when bufferFile gets aroubd 65xxx bytes, it seems to be resetted. And it starts functioning unexpectedly.

d_stranz
23rd July 2018, 18:16
I do not think there is any built-in size limit on QByteArray. But since you haven't shown us any real code ("QbytesArray" isn't the name of a Qt class), or how you are actually receiving the data you are pushing into the QByteArray, the mistake could be anywhere in your code and probably doesn't have anything to do with QByteArray itself.

Pereubu2018
24th July 2018, 09:07
Ok. The problem is how to debug that, because I have to do that in real time environment!
The problem is that I have problem with my reading files..
here is cpp:
void CommunicationClass::readyReading()
{
int receivedBytes;
QByteArray bufferTotalFile;
QByteArray buffer; // errCounter UDP buffer // Qbytearray is found as solution for dealing with huge array of bytes
QByteArray bufferTotalBackup; //QArraybytes backup
buffer.resize(4096);
const unsigned char *endSignature;
unsigned char receiveBufferUdpImage[4096];
QHostAddress sender;
quint16 senderPort;
int testsize = 0;
receivedBytes = 0;
/* that is endless loop to read what is coming from UDP sockets*/

/* endless loop */

while (mainudp->hasPendingDatagrams()) {
quint64 size = mainudp->pendingDatagramSize();
buffer.resize(size);
mainudp->readDatagram(buffer.data(), size, &sender, &senderPort);
memcpy(receiveBufferUdpImage, buffer.data(), size);

//
// The start of JPEG File is marked by first byte is FF while second byte is D8
//
if ((receiveBufferUdpImage[0] == 0xFF) && (receiveBufferUdpImage[1] == 0xD8) && (startDetect == false))

{
startDetect = true; //stratJpegfile to insure that we are expecting the end jpeg
bufferTotalFile.clear();
}

//
// The start of JPEG File is marked by first byte is FF while second is D8
//


// mytesting
static int errCounter = 0;

if (errCounter == 280) {
++errCounter;
}
if (receivedBytes != bufferTotalFile.size()) {
++errCounter;
}
else {
++errCounter;
}

receivedBytes += buffer.size();
bufferTotalFile.push_back(buffer);
testsize = bufferTotalFile.size();

if (receivedBytes != bufferTotalFile.size()) {
++errCounter;
}
else {
++errCounter;
}


// The procedure how to detect end of JPEG file

const unsigned char *endSignature = (unsigned char *)&receiveBufferUdpImage[size - 5];

if ((startDetect == true) && (
((endSignature[2] == 0xFF) && (endSignature[3] == 0xD9) && (endSignature[4] == 0xFF)) ||
((endSignature[3] == 0xFF) && (endSignature[4] == 0xD9))))

{
startDetect = false;
receivedBytes = 0; // reset to start a new file
bufferTotalBackup = bufferTotalFile; //copy that buffer to backup buffer
emit sendImage(bufferTotalBackup); // sending the signal that the file is detected
}
}
}
and here is .h
#pragma once

#include <QObject>
#include<qudpsocket.h>


class communicationClass: public QObject
{
Q_OBJECT

public:
explicit communicationclass(QObject *parent = 0);
~communicationClass();

signals:
void sendImage(QByteArray&);

public slots:
void readyReading();

private:
QUdpSocket * mainudp;
int receivedBytes;
QByteArray bufferTotalFile;
bool startDetect;
//QByteArray receivedBytes;
};

Pereubu2018
24th July 2018, 15:11
I have included this:
The both parameters are equal but I am having problem that both are being reset to zero without getting (meaning detecting end sequence) to the end of image file. The problem is what I why they are reset. There is no reason to get to zero?
qDebug() << receivedBytes << testsize;

128160 128160
...
162108 162108
1440 1440 ???
2880 2880
...
14400 14400
1440 1440 ???
2880 2880
..
152352 152352
1440 1440 ????
2880 2880
..
145440 145440
146492 146492
1440 1440
2880 2880
...
21600 21600
1440 1440
2880 2880
...
17280 17280
18720 18720
1440 1440
2880 2880
..
136800 136800
138240 138240
1440 1440
2880 2880
...
7200 7200 etc etc etc..


receivedBytes += buffer.size();
bufferJpegFile.push_back(buffer);
testsize = bufferJpegFile.size();

That is the point where maybe reseting to zero?

Pereubu2018
25th July 2018, 11:57
In fact I am wrong because there are times when the system is out of loop because there is no pendingDatagrams etc.. I have to fix the problem..