Memory free

Joe von Habsburg

Hello, I work on a project. On UI, I have 2 buttons.
Add button : Create object.
Delete button : Delete last object.

When I use delete button, memory could not be free.
What should I do? Does not deleteLater() work?

class MyClass : QBject{
 MyClass();
~MyClass(){
   //delete all probs like that:
   someThingPointer->deleteLater();
   someThingPointer = nullptr;
   someThing.deleteLater();
 }
private :
 SomeThingPointer *someThingPointer;
 SomeThing someThing;
}




void on_add_click(){
 emit addNew();
}

void on_delete_click(){
 emit deleteLast();
}

void addNew(){
  MyClass *mc = new MyClass(...);
  myClasses.append(mc);
  newConenctions(mc);
}

void deleteLast(){
  MyClass *mc = myClasses.last();
  deleteConnections(mc);
  mc->deleteLater();
  myClasses.removeLast();
}


void newConenctions(MyObject *mc){
 //connections 
}

void deleteConnections(MyObject *mc){
 //disconnections 
}

JonB

@Joe-von-Habsburg
Yes, deleteLater() works. Pointer is only freed when your code allows Qt top-level event loop to be re-entered. However, C++ delete does not return memory to the OS, it only allows to be re-used in your application at a later time, so if you are looking at OS report you won't see free memory increase. Use a tool like valgrind to analyze your application for leaks.

Joe von Habsburg

@JonB said in Memory free:

valgrind

I work on windows and I could not see Valgrind for windows. Can you suggest another application ?

JonB

@Joe-von-Habsburg The VS/MSVC has some memory analyzer of its own.

Pl45m4

@Joe-von-Habsburg said in Memory free:

someThing.deleteLater();

This makes no sense... (delete object on stack)

Also if your class is a QObject and has a parent, you don't need to worry about deletion. QObjects are deleted when their parent gets cleaned up.

Don't trust Valgrind too much, it can report memory leaks in QObjects even when there aren't any.

Joe von Habsburg

@JonB said in Memory free:

Pointer is only freed when your code allows Qt top-level event loop to be re-entered.

What is that mean?

@JonB said in Memory free:

However, C++ delete does not return memory to the OS,

Can I use "free" command like in C ?

free(mc)

@JonB said in Memory free:

it only allows to be re-used in your application at a later time,

If I spaming delete and add buttons, There will lots of using memory (I need 500mb but I spam the buttons and endures to the end).

@JonB said in Memory free:

if you are looking at OS report you won't see free memory increase.

Note : If I do not anything, memory is stable. There is no bad in code that increases memory.

@Pl45m4 said in Memory free:

Also if your class is a QObject and has a parent, you don't need to worry about deletion. QObjects are deleted when their parent gets cleaned up.

Do you have any idea ? Why my memory always increase?

@Pl45m4 said in Memory free:

Don't trust Valgrind too much, it can report memory leaks in QObjects even when there aren't any.

I tried valgrind on ubuntu (valgrind --leak-check=full ./app) but I dont understand anything :D

jsulm

@Joe-von-Habsburg said in Memory free:

Why my memory always increase?

How do you actually analyze the memory consumption of your application? As @JonB pointed out already freeing some memory does not necessarily mean that tools like Windows Task Manager will show less memory consumption for your application. The OS can still hold the free memory for the application in case it again requests memory.

Joe von Habsburg

@jsulm said in Memory free:

How do you actually analyze the memory consumption of your application?

I watch on task manager. When Its stable (I do not anything, but processes are working background), it is using 300mb around.

@jsulm said in Memory free:

As @JonB pointed out already freeing some memory does not necessarily mean that tools like Windows Task Manager will show less memory consumption for your application.

Yes but how can I understand, How many memory I use actually ? Is there any QClass?

@jsulm said in Memory free:

The OS can still hold the free memory for the application in case it again requests memory.

Yes It is keeping memory and always increase an using memory.

jsulm

@Joe-von-Habsburg said in Memory free:

Yes It is keeping memory and always increase an using memory.

How long did you observe this? At some point the memory should not increase anymore.
And as already mentioned: if you want to properly analyze memory consumption and look for memory leaks you have to use proper tools, not task manager.

Joe von Habsburg

@jsulm said in Memory free:

How long did you observe this? At some point the memory should not increase anymore.

I spammed buttons many times, Its increased. I quit program after It used 15GB Ram. My computer has 64GB ram. Is it a reason? Because It can increase? There is lots of free space.

@jsulm said in Memory free:

And as already mentioned: if you want to properly analyze memory consumption and look for memory leaks you have to use proper tools, not task manager.

What's your recomended application ? I look task manager, resource monitor and performance monitor. These are windows's applicatons.

@JonB said in Memory free:

VS/MSVC has some memory analyzer of its own.

I use QtCreator, unfortunately debug profile cant work

JonB

@Joe-von-Habsburg said in Memory free:

I use QtCreator, unfortunately debug profile cant work

I don't know if "debug profile" is what is needed, but whatever the tool is if Creator does not offer an interface to it you will presulably need to run it under that tool (however you do that) outside of Creator.

I look task manager, resource monitor and performance monitor

None of these are suitable, none can tell you what areas of memory allocated by your application might have been freed in C++ but are re-allocatable by C++ at a future point.

I quit program after It used 15GB Ram.

Since "I spammed buttons many times" could mean anything from, say, 5 to a million it's not possible to say for sure. But anything which eats GBs of memory for some pushbuttons is clearly not right.

Joe von Habsburg

@JonB said in Memory free:

Since "I spammed buttons many times" could mean anything from, say, 5 to a million it's not possible to say for sure. But anything which eats GBs of memory for some pushbuttons is clearly not right.

So many times I clicked the buttons. add delete add delete add delete .... maybe a hundred times

@JonB said in Memory free:

None of these are suitable,

whats your recomended without valgrid ?

Joe von Habsburg

@JonB said in Memory free:

Yes, deleteLater() works.

I have another question. I do something with MyClass object in loop

void run(){
  for(int i = 0; i < myClasses.size(); i++){
    MyClass *mc = myClasses.at(i);
    mc.doSth();
  }
}

Is memory leak able to be for that reason ? Must I delete or do something ?

JonB

@Joe-von-Habsburg said in Memory free:

whats your recomended without valgrid ?

I answered that previously if you are using MSVC/VS under Windows. If you are using MinGW I don't know. I do not use Qt under Windows.

Is memory leak able to be for that reason ? Must I delete or do something ?

The code you show (seems to) just access an element in whatever type of collection myClasses is (apparently, a collection of MyClass * pointers). There is no "leak" here in itself.

Pl45m4

@Joe-von-Habsburg said in Memory free:

MyClass *mc = myClasses.at(i);
Must I delete or do something ?

Depends on how you create the objects in myClasses.
myClasses is a Q-container of QObjects?!
If they are QObjects and have a parent, then you don't have to do anything, because they will be deleted when parent is deleted. But be careful not to access the pointers in other places, if so. Always check for nullptr or use something like QSharedPointer when passing QObjects around.

I would recommend you to read this:

JonB

@Pl45m4 said in Memory free:

Depends on how you create the objects in myClasses.

I don't see how that is relevant. [Assume OP means mc->doSth() rather than mc.doDoSth(), which won't compile.] So it's just a pointer, and a method is called on it. The OP asked about memory leak or deleting because that what this topic is about, I understand what you are saying [perfectly valid advice] but just don't see how they are related.

Pl45m4

@JonB said in Memory free:

Assume OP means mc->doSth() rather than mc.doDoSth(), which won't compile.

I wasn't after that :) I've noticed it but it also doesn't matter.
Maybe the part I've quoted was a bit misleading. Fixed it.

My point was, when elements in the container are QObjects with a parent, there is nothing to do and you don't have to delete them manually.

SimonSchroeder

@Pl45m4 said in Memory free:

My point was, when elements in the container are QObjects with a parent, there is nothing to do and you don't have to delete them manually.

This is only partially true. In the OPs case he continuously adds and removes QObjects to a container. I would expect that the parent will live a lot longer. Thus, deleting the objects manually once they are removed from the container is a good idea. If the parent lives until the end of the program, you would never free any memory automatically. (The OP posted code for deleteLast() that both removes the object from the container and calls deleteLater() on it.)

@Joe-von-Habsburg said in Memory free:

So many times I clicked the buttons. add delete add delete add delete .... maybe a hundred times

If you are are alternating between clicking add and delete, the amount of memory used should not change (you seem to be running the event loop as clicks are registered; and thus deleteLater() should do its job). Only clicking add repeatedly should increase memory. If you want help with your code we would need a minimal compilable example that reproduces the problem. There could be something wrong anywhere in you whole code.

On Windows the best tool (at least the best tool I know) for debugging is Visual Studio. Debugging inside Qt Creator is awfully slow on Windows (the slower the larger your projects gets). With qmake-based projects you can call qmake on the command line to create a fresh VS project and run that to debug or inspect memory usage (or profile performance). With CMake-based projects you can just open them up inside VS.

Helmut.Jakoby

@SimonSchroeder said in Memory free:

...
On Windows the best tool (at least the best tool I know) for debugging is Visual Studio. Debugging inside Qt Creator is awfully slow on Windows (the slower the larger your projects gets). With qmake-based projects you can call qmake on the command line to create a fresh VS project and run that to debug or inspect memory usage (or profile performance). With CMake-based projects you can just open them up inside VS.

I have the same opinion about Visual Studio C++. Even though I generally use mingw for my projects on Windows, I always use Visual Studio C++ for debugging.
I once took the trouble to write a "Memory Leak Indicator" for "new/delete" that shows the file name and line number in which an object that has not been released was instantiated. I like using it with Qt because I still work a lot with pointers there.

Pl45m4

@SimonSchroeder said in Memory free:

This is only partially true. In the OPs case he continuously adds and removes QObjects to a container. I would expect that the parent will live a lot longer. Thus, deleting the objects manually once they are removed from the container is a good idea. If the parent lives until the end of the program, you would never free any memory automatically. (The OP posted code for deleteLast() that both removes the object from the container and calls deleteLater() on it.)

Yes, and I dont want to start nitpicking... but I didn't wrote anything else :)
Of course, when you want to re-create the instance, the old one should be free'd correctly. At the very beginning @Joe-von-Habsburg also posted a snippet where he showed deleteLater() on a stack member inside class destructor :)