Solved Valgrind: possible memory-leak when setting up connections
-
@unzu said in Valgrind: possible memory-leak when setting up connections:
StateDevice.cpp:31
So what's at this line?I think you can't fix it and it's Qt internal. As long as it's only 1 block it's not really a leak which should worry you.
/edit: you leak DataDevice
-
@Christian-Ehrlicher
Oh! Thats definitely a leak, i forgot to pass the parent object to the QObject in the initializer-list.
Fixed that, thanks. Should now be on github, too.
The leaks are still detected, though :(
So you think I should just go with it?
I've spend already multiple days looking for a solution and hints on the internet, guess i really have to move on - it's just that those tiny details drive me nuts. -
@unzu said in Valgrind: possible memory-leak when setting up connections:
So you think I should just go with it?
yes, as long as it's only 1 block - so the 'leak' only occurs one time it's fine. It can e.g. an initialization of a Qt internal memory block which is needed for connections and is never deallocated since it's needed until the very end of the program.
-
@Christian-Ehrlicher The thing is, I intended to call this 'driver' multiple times, maybe even many thousand times in the lifetime of the program.
Like 48 times a day per device, multiple devices, and the program is running in endless mode.Do you know if there is way to see the total memory consumption of a program? So that I can create and delete the statemachine like 10000 times and see if the memory size is rising?
-
So when you call it multiple times and only one block leaks my explanation is correct, or? It's a one-and-only allocation.
-
I don't think so, maybe I'm getting this wrong, but everytime I create a new instance of my statemachine it creates those connections inside which maybe cause leaking?
-
@unzu said in Valgrind: possible memory-leak when setting up connections:
which maybe cause leaking?
Again: valgrind only shows "160 bytes in 1 blocks" - no matter how often you call it, so how do you think it will leak every time you call it?
-
Sorry, I probably don't understand what's really happening here. I thought that whenever I create an instance of the statemachine there is some memory allocated which is not freed on deletion of the statemachine, so that for every instance there is some lost memory until I stop the application or run out of memory.
Again, I'm no expert and just trying to build a small application that won't crash after x hours of usage..
-
@unzu said in Valgrind: possible memory-leak when setting up connections:
I thought that whenever I create an instance of the statemachine there is some memory allocated which is not freed on deletion of the statemachine, so that for every instance there is some lost memory until I stop the application or run out of memory.
Then you would see more than one of such valgrind warning or more than one block allocation, or?
-
Ah I see - so if a leak would happen everytime I create a new instance of the object, the number of blocks would increase?
I compiled the project with Visual Studio because you can see the process-memory easily there.
After fixing another leak I found in one of the subclasses of the statemachine-class the process memory stayed steadily on ~13MB, even after creating and deleting more than 100.000 instances of the statemachine.So i think (if there is really a leak) that it is, as you have suggest, once in the lifetime of the program.
-
@unzu said in Valgrind: possible memory-leak when setting up connections:
I create a new instance of the object, the number of blocks would increase?
correct, therefore I suspect it's some static memory internally needed for the signal/slot handling and can be ignored. You just have to start worring about a 'leak' when it increases with the times you call a function. If it stays at a specific (small) amount it's fine. Esp. when the amount is 1 :)