Qdialog causing memory leak?

liewjls

Hi,

I have a program which will need to create few qdialog depends on the user. My QDialog contains quite a few widgets, buttons and textline, they are created using Qt Designer UI. which all the buttons, textline and widgets etc are being created in my .UI file. I think i have some memory leak whenever i have create and close the dialog, I tried run valgrind, it didn't complains about my qdialog but when "top" commands shows the memory percentage doesn't go down after i create and close dialog.

I have set my qdialog with WA_DeleteOnClose in my QDialog constructor as few ppl suggested.


Dialog::Dialog(QWidget *parent) :
    QDialog(parent),
    ui(new Ui::Dialog)
{
    ui->setupUi(this);
    setAttribute(Qt::WA_DeleteOnClose, true)
}

Dialog::~Dialog()
{
    qDebug() << "Dialog object is being deleted!";
    delete ui;
}

i used deleteLater() to delete my Dialog. Will this cause any memory leak? Does this will automatically delete all my widgets, buttons and textline?

    Dialog * dialogObj = new Dialog;
    dialogObj->deleteLater();

Thanks.

jsulm

@liewjls Why not just

delete dialogObj;

as soon as you do not need the instance any-more?
Deleting the dialog deletes all its widgets.
Can you show how you are using the dialog?

Suares

said in Qdialog causing memory leak?:

when "top" commands shows the memory percentage doesn't go down after i create and close dialog

It doesn't mean that you have a memory leak.

Chris Kawa

Using Qt::WA_DeleteOnClose in a constructor is a bad bad idea. If someone creates an instance of that class on a stack you've got a crash. Same thing if you allocate on a heap and try to delete it after it was closed.

Deleting an object doesn't mean that the OS will instantly free all resources associated with a process. Memory managers are a large scale garbage collectors. As @Suares said it doesn't mean you've got a memory leak. What matters is if the amount of memory you free is the same as you allocated.

ambershark

@liewjls Like @Suares said, don't watch top for memory leaks. It doesn't work like that.

Read up on how the OS allocates and frees memory pages to better understand why your memory in use doesn't go down after you free something. Especially something as small as a QDialog.

If valgrind is not reporting a leak, then you don't have a leak. :)

liewjls

Thanks.
I did use valgrind to check on the memory on my development machine. But! I got a problem, some of the codes need to run on a PC which the PC is running on OpenSuse 11.3 and I couldn't run valgrind to check everything is working OK.

@Chris-Kawa oh, where should I use Qt::WA_DeleteOnClose then?

thanks.

nestorac

Memory is probably reserved for the cache. You should try "free -m" to see the overall values. But I agree, it's not a memory leak. It's just the OS creating objects and reserving then the memory left when those objects get destroyed for other purposes. Nothing new. You can see how the memory gets more used as time passes in Linux. This is about the kernel itself.

Chris Kawa

@liewjls said in Qdialog causing memory leak?:

oh, where should I use Qt::WA_DeleteOnClose then?

This flag should be passed by the user of your class, where the information about the lifetime of the object is. This is usually at the place the instance of that class is created.
For example:

void SomeClass::showDialog() {
    Dialog* dialogObj = new Dialog(this); //parents are important!
    dialogObj->setAttribute(Qt::WA_DeleteOnClose);
    dialogObj->show();
}

Here you know what the lifetime is i.e. it is created on the heap so it won't be deleted automatically when going out of scope. If the parent is deleted it will also delete the dialog. If the user closes the dialog it will also be deleted via the flag. The user of the Dialog class (i.e. SomeClass instance) fully governs the lifetime of the instance it creates and doesn't need to rely on internal implementation of the Dialog class.

Parents of dialogs are important (as I noted in the comment). They keep the proper stacking order of the windows and assure proper focus switching handling. It's also easier to manage lifetime of such dialog because it is assured that there's no leak (parent always deletes its child). You can always call deleteLater() earlier if you need to, but there's no danger that some code path will not call it and thus leak.

jsulm

@liewjls Why couldn't you use Valgrind on OpenSuse?

liewjls

Hi @jsulm

Not sure why thought. When i tried to run valgrind on the machine, i got the error message

==4849== Command: ./test--platform xcb
==4849== 
--4849-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x2a

valgrind: m_debuginfo/readdwarf.c:2199 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.
==4849==    at 0x380273D0: ??? (in /usr/lib/valgrind/memcheck-x86-linux)

sched status:
  running_tid=0

I only download and install the valgrind and debuginfo rpm from the opensuse respo.
Anyone can help me on that?

thanks.