Important: Please read the Qt Code of Conduct -

Memory leak with QDialog

  • Hi guys!

    I got a big problem building a embedded application to linux arm using Qt
    My machine has only 30MB of RAM, so i do realy need free any memory usage when leave some interface...

    I'm using QDialog to each interface in application, i've 18 interfaces/QDialogs, the problem is that when i close a QDialog, the amount of memory alocated to this dialog keeps in RAM even it's closed :(

    INside a QMainWindow, i create and call a QDialod like this: (At this moment, the application is using 8MB of RAM)

    //Create the form
    this->frm_menuMain = new frmMenuMain(this); //It's a qdialog
    this->frm_menuMain->setAttribute(Qt::WA_DeleteOnClose, true);
    connect( this->frm_menuMain, SIGNAL(finished(int)), this, SLOT(onFinishedMainMenuForm(int)));

    //Send delete
    void frmMain::onFinishedMainMenuForm(int sts){
    qWarning() << "deleteLater()";

    After open the QDialog, the application is using 11MB of RAM

    Inside the QDialog, when press a button, i close the form using

    @void onPressed(){ this.close();}@

    When the QDialog is closed, the QMainWindow appears again, and the memory usage keeps 11MB, if i open another QDialog, the memory usage increase again!

    I tryed to do (after sometime closed the qdialog)

    @delete this->frm_menuMain;@

    but the application close with segmentation fault!

    Can someone help me? how could i free the memory usage after close the qdialog?
    this way, after open/close around 6 QDialogs my aplication is using more then 100% of memory, the linux starts to swap memory and it gets so slowly....

  • So, you say that when you destroy the dialog, the memory usages goes back to the initial value, but goes up again, if you create a new dialog later? Well, I would say that is expected behavior. Of course it goes up again, when you create a new dialog. So I cannot currently understand the problem.

    I suggest you do the following: Create a new dialog, show it and then destroy it. Repeat this many times in a loop - without restarting the application. If that causes a continuous increase in memory usage (until your application crashes with "out of memory" eventually), then you have a memory leak somewhere. Otherwise, if memory usage keeps constant at some point, you don't...

    Anyway, why not simply do it like this:
    @frmMenuMain *dialog = new frmMenuMain(this);
    dialog->exec(); //this blocks while dialog is showing!
    delete dialog; //Let's clean up right away!

    There should be no need to store the pointer to the sub-dialog in a global variable or a member variable of your main dialog. Just use a local variable.


    Furthermore, a general advice: If you think there's a memory leak somewhere in your application, I would recommend to use "VLD": (Windows) or Valgrind (Linux) in order to track it down...

  • actually the memory usage doesn't back when i close the dialog, even after closed the memory usage keeps the same that the dialog is open.

    So i think the point is do delete in dialog pointer, but my app is crashing when i do this

    I'll try to use a local pointer of frmMenuMain() instead of global pointer, like you said.
    Thanks for reply!

  • [quote author="GeTaylor" date="1398035404"]actually the memory usage doesn’t back when i close the dialog, even after closed the memory usage keeps the same that the dialog is open.[/quote]

    But what if you repeatedly show the dialog, many times? Does the memory usage grow on and on? If it doesn't, you might not have a leak, after all.

    [quote author="GeTaylor" date="1398035404"]So i think the point is do delete in dialog pointer, but my app is crashing when i do this[/quote]

    Then probably somewhere in your code you are accessing the pointer to the dialog after it has been deleted already! But it's impossible to give more advice without knowing your code. Still, keeping the pointer in a local variable minimizes the chance of such "use after free" errors. Furthermore, you should make a Debug build of your application and then look at the Stacktrace when it crashes. This way you can track down where exactly it crashes.

    BTW: If your dialog itself happens to have some memory leak inside, then deleting the dialog alone won't be sufficient. Therefore, also be sure that the dialog itself performs proper clean-up in its destructor code.

Log in to reply