Unsolved QtCreator Debug Memory Allocation
-
@koahnig I've just added
reserve
with a length of 1024. I'll let this run for a while and see what happens.As I mentioned above, the size never goes above 100 bytes (only simple NMEA GPS strings) so 1024 is overkill really.
-
I think you are looking at the wrong end. The returned QByteArray, which is filled with 100 Byte or so each time, shall bear no problem.
@webzoid said in QtCreator Debug Memory Allocation:
@koahnig I'm
appending
to aQByteArray
on a very frequent basis. I'll try and explain more...My application receives data from a number of serial port devices (like GPS, etc). Each device class has a
readBuffer
field which is aQByteArray
and every time theQSerialPort::readyRead
signal is emitted, I capture all available data (usingQSerialPort::readAll
) and append it to myreadBuffer
field ready for processing. Once data is processed, the processed bytes are removed from thereadBuffer
.You wrote about appending on a frequent basis to a QByteArray. If you are receiving at 1 Hz 100 Byte you are going past the 1024 already 6 times minute. The issue should be with what you call there
readBuffer
. When you overwrite all the time, it should be fine. If you extend this all the time and it will grow and create the problem.However, without some sort of comprehensive code snippet showing your intend it is hard to get the right names and understanding what you are trying to do.
-
@koahnig Sorry, I probably haven't explained this very well.
It is the
readBuffer
(i.e. my class field) which only every gets to about 100 bytes in size. As soon as I've processed thereadBuffer
and obtained all the information I need, I clean out the bytes which have been processed (usingremoveTo
) and then go again.The code I use to read from the
QSerialPort
is here:void SerialDevice::readBytes() { // Read all available bytes from the port if (m_port.bytesAvailable()) { // Read the bytes into a buffer QByteArray buffer = m_port.readAll(); // Append to the main read buffer this->readBuffer().append(buffer); // Process the read buffer processReadBuffer(); } }
I'm confident that there is no real issue with the code above.
-
@webzoid said in QtCreator Debug Memory Allocation:
this->readBuffer().append(buffer);
This looks strange: what does readBuffer() do?
-
@jsulm It returns a reference to the
QByteArray
- its defined in a base class.QByteArray& readBuffer() { return m_readBuffer; }
-
Hi,
What does
processReadBuffer
do ? -
@webzoid said in QtCreator Debug Memory Allocation:
@koahnig Sorry, I probably haven't explained this very well.
It is the
readBuffer
(i.e. my class field) which only every gets to about 100 bytes in size. As soon as I've processed thereadBuffer
and obtained all the information I need, I clean out the bytes which have been processed (usingremoveTo
) and then go again.QByteArray does not have a routine called removeTo.
Is that routine from you as well?
-
@koahnig Apologies, I mean't the
remove
function, notremoveTo
.@SGaist
processReadBuffer
converts theQByteArray
to aQString
and attempts to validate a NMEA string. If a valid string is found, the relevant bytes are removed fromreadBuffer
ready for the next lot of data to arrive.Either way though, I don't believe that this has anything to do with what I'm trying to find out.
I just want to know whether QtCreator allows inspection of heap sizes reserved by objects, or objects memory footprints. There is a memory leak, no doubt, but it's proving very hard to find: all local
malloc
s have their ownfree
, allnew
instances aredelete
d where necessary, allQList
s are cleared when required -
For sure it is a nightmare with having many pointers and memory allocations and a memory leak in addition. However, there is typically the problem. Unfortunately, you are the only one to solve this.
As a general I would go for either malloc and free or for new and delete. My personal decision is to limit myself to new and delete and not mixing with malloc and delete. Some of the other fellows might correct me, but I believe they might coexist, but you have to careful for not confusing yourself.
In addition I am using shared pointers, which have the disadvantage of some overhead, but are taking away a lot of memory frustration. Nevertheless, they are the overall cure of memory leaks.
Personally I started with shared_ptr from boost which is now part of the C++ standards. There are also Qt alternatives such as QSharedPointer and its fellows.
-
-
@jsulm said in QtCreator Debug Memory Allocation:
@webzoid Take a look at http://doc.qt.io/qtcreator/creator-valgrind-overview.html
For me as a windows driven developer is valgrind outside of the horizon. A port to windows started a while ago but was too slow to pick off AFAIK.
There is apparently something "new" with http://drmemory.org/ in open source for all platforms. I am wondering if this is any good.
-