Auto-generate ui header & memory leak?

[MorrisLiang]

I'm checking where is the memory-leak happening in my app.And find out this:


void setupUi(QWidget *MyWidgetClass)
{
...
hLayout1 = new QHBoxLayout();
...
verticalLayout = new QVBoxLayout();
...
horizontalSpacer_2 = new QSpacerItem(40, 20, QSizePolicy::Expanding, QSizePolicy::Minimum);
...
verticalSpacer = new QSpacerItem(20, 40, QSizePolicy::Minimum, QSizePolicy::Expanding);
...
} // setupUi

In one of the generated ui header,in the setupUi() function,there are things created in the heap.And they don't set the parent.So,when I'm done with the QWidget,this would defintely cause memory leak if I don't manually delete them.

I know nothing is perfect,but I thought the generated file would deal with the parent thing.
So each time it generate a new version of file,do I have to check if they have set the widget's parent?Is there a way avoid this?

BTW,does someone how if there's a free memory-leak detector for c++(Windows platform)?



----------------------EDIT-----------------------------
OK,I see that they are added to another layout.Then they would be deleted if the custom QWidget is deleted.So,where is the common place of the leak?Where should I pay attention to?

[squidge]

There is no "someObject->addLayout(hLayout1)" for example?

[Zlatomir]

The auto generated setupUi(QWidget *MyWidgetClass) will be called most likely in the class constructor with parameter "this" witch will parent all the members.

*** The widgets can be created without parent, if they are added to a layout, they get "adopted" even if the layout don't have a parent, he gets one when we call some_widget->setLayout(...), and set all widgets parent.

Post the complete source code of setupUI, or look carefully, you will see that eventualy everything gets parents.

LE: if some widget remains without a parent, you will notice that it won't appear when you call show() on parent (because you don't show each individual widget separate, you call show on one instance of the class ;) )

*** To express correct: the layout doesn't actually have a parent: QHBoxLayout *l = new QHBoxLayout(window); means that all the widgets added to the layout l will be auto-parented to window.

[MorrisLiang]

Yeah,I look at the code again, and find the line
"someObject->addLayout(hLayout1);"
Everything has a parent,so they're not causing the leak.

And here's another problem:
At first,my app is using 17000K memory.
I have a button,clicking it will create a statck-based custom dialog.This action costs nearly 1M memory.So now it's 18000K.
Then I close it,I get back 300K,that is 17700K now.
But shouldn't it go back to 17000K when I close the dialog?

[Zlatomir]

Disclaimer: I'm not an expert in operating systems,

But i'm pretty sure that what you see in task-manager (or Linux/other OS or utility) isn't the actual memory occupied by your application, but it is the memory that your OS "spare" for your application (so if you close the 1M dialog, the OS doesn't instantly re-claims the 1M memory, it leaves your app with a little more, so it wont have to allocate/de-allocate memory, if you open the dialog again, so your app will have a "stack" in total memory available for the OS)

[wysota]

Are you sure you are measuring the memory in the appropriate way? System tools will likely give you an incorrect result.

[MorrisLiang]

I'm watching windows task manager actually.
Thanks for all the information,I try to open/close the dialog several times,the memory doesn't boost.So,I guess it's not a leak.

[wysota]

I'm watching windows task manager actually.
Yep, that's one of the tools giving incorrect values :)

[squidge]

There are much better tools, such as Valgrind.

[wysota]

Or any dedicated to tracking memory use implementation of malloc and free.

[squidge]

I've changed malloc and free before - it doesn't catch new and delete calls :(

[wysota]

I've changed malloc and free before - it doesn't catch new and delete calls :(

I'm sure there are ways to do it. I think even Qt offers to substitute malloc with something else (but I may as well be day dreaming right now). Valgrind is unfortunately not an option for people who develop only on Windows.

[squidge]

For Windows people, Visual C++ provides built-in memory leak detection.