double free or corruption (out) when closing a QDialog with the WA_DeleteOnClose attribute set

J.Hilk

I don't hink its unexpected,

you see the first deletion in your console output

~MyDialog()

after that the program tries to call delete the object that is already deleted.

-> the destructor is of course not called again (no instance to call it upon) but you get the double free exception

LRDPRDX

@jsulm I don't think so. As you see the output "After exec" is not present. So the error occurs before leaving the scope..

LRDPRDX

@J-Hilk I would agree with you if I had seen the "After exec" line in the output.

J.Hilk

@LRDPRDX you're right.

it's more sinister.

the QDialog implementation of delete on close is a delete this call. 😱 very naughty, even if allocated on the heap.

so its not double free call, it's corruption.

class MyPDialog : public QDialog
{
public:
    MyPDialog(QWidget *parent = nullptr) : QDialog(parent) {}

    void deleteOnClose() {delete this;}

    ~MyPDialog()
    {
        qInfo() << "~MyPDialog()";
    }
};


int main(int argc, char *argv[])
{
    QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
    QApplication app(argc, argv);

    MyPDialog d;
    d.deleteOnClose();
//    d.setAttribute( Qt::WA_DeleteOnClose, true );
//    int result = d.exec();
    qInfo() << "After exec" /*<< result*/;

    return app.exec();
}

kshegunov

@J-Hilk said in double free or corruption (out) when closing a QDialog with the WA_DeleteOnClose attribute set:

it's more sinister.

There's nothing sinister, the OP already provided the answer.

@LRDPRDX said in double free or corruption (out) when closing a QDialog with the WA_DeleteOnClose attribute set:

I suspect that the deleteLater() function is not allowed to be called on a stack variable but to confirm I (probably) need to go through the QCoreApplication::postEvent() function which is too complicated to me as a user and not a Qt-developer.

No, delete is not allowed on a stack variable. You don't need to be a Qt developer to know this, and it has nothing to do with how you call the delete -- from the outside, from the inside (i.e. deleting this), through a custom event or without.

JonB

@kshegunov said in double free or corruption (out) when closing a QDialog with the WA_DeleteOnClose attribute set:

No, delete is allowed on a stack variable

Do you perchance mean delete is not allowed on a stack variable?

Oh, you updated your post after I posted this :)

kshegunov

@JonB said in double free or corruption (out) when closing a QDialog with the WA_DeleteOnClose attribute set:

Do you perchance mean delete is not allowed on a stack variable?

Indeed, it was a typo.

JonB

@kshegunov
A "typo" is a misspelling, not a complete reversal of a comment's intention! :D

And I agree it's about time somebody said you just must not delete a stack variable, period. [Whether WA_DeleteOnClose docs might mention that is what this does, and so should only be used on heap instances, is another matter. I was never clear just what exactly WA_DeleteOnClose did, though I used it.

J.Hilk

@kshegunov said in double free or corruption (out) when closing a QDialog with the WA_DeleteOnClose attribute set:

There's nothing sinister, the OP already provided the answer.

no matter what, telling a class to commit suicide is sinister in my books :P

LRDPRDX

@J-Hilk Cool -_-

the QDialog implementation of delete on close is a delete this call

Just to ensure : do you know this from this (line 613) ?

J.Hilk

@LRDPRDX yes, its exactly where my debugger stopped.

kshegunov

@JonB said in double free or corruption (out) when closing a QDialog with the WA_DeleteOnClose attribute set:

A "typo" is a misspelling, not a complete reversal of a comment's intention! :D

I added the comma after the fact, which introduced the missing negation, so *shrug* happens.

@J-Hilk said in double free or corruption (out) when closing a QDialog with the WA_DeleteOnClose attribute set:

no matter what, telling a class to commit suicide is sinister in my books :P

Your books are wrong. We are a free-haven! ;)

JonB

@kshegunov said in double free or corruption (out) when closing a QDialog with the WA_DeleteOnClose attribute set:

I added the comma

Eats, Shoots & Leaves ;-)

mpergand

At the end of the QDialog:exec there are:

if (deleteOnClose)
        delete this;
return res;

On Mac i got:
malloc: *** error for object 0x7ffeefbffa60: pointer being freed was not allocated
so it crashes at the delete instruction and never returns.

JonB

@LRDPRDX OOI, which compiler, compiler options (debug/release) & platform are you on for your error message?

LRDPRDX

@kshegunov said in double free or corruption (out) when closing a QDialog with the WA_DeleteOnClose attribute set:

You don't need to be a Qt developer to know this, and it has nothing to do with how you call the delete -- from the outside, from the inside (i.e. deleting this), through a custom event or without.

Agreed, but how do I know what the Qt::WA_DeleteOnClose actually does? One can guess it causes the call of delete on the variable but that was just not enough to me to be sure (and obviously I was looking for an answer in the wrong place in the source code). Anyway, now I've got the answer. Thank you.

kshegunov

@LRDPRDX said in double free or corruption (out) when closing a QDialog with the WA_DeleteOnClose attribute set:

Agreed, but how do I know what the Qt::WA_DeleteOnClose actually does?

If you feel the name doesn't give it up, or isn't clear enough, I'd've suggested looking up in the documentation:
https://doc.qt.io/qt-5/qt.html#WidgetAttribute-enum

It's sort of the point of having documentation - so you don't need to go browsing through the code, and thankfully Qt has the best one I've ever seen.

LRDPRDX

@kshegunov Yes, ofc, I read that. For some reason I interpret the word "delete" (when it's not formatted :) ) as a general way to destroy an object. -_-

habeebo

@LRDPRDX

In terminal, "double free or corruption (out)" message is printed after the destructor has been called.

Update: Sorry for bothering you. I was having similar issue. I saw your post in stackoverflow and then my problem solved when I allocated my QMainWindow object in heap instead of the stack.

Many thanks!