double free or corruption (out) when closing a QDialog with the WA_DeleteOnClose attribute set
-
@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
deleteis not allowed on a stack variable?Oh, you updated your post after I posted this :)
@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.
Read and abide by the Qt Code of Conduct
-
@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.
@kshegunov
A "typo" is a misspelling, not a complete reversal of a comment's intention! :DAnd I agree it's about time somebody said you just must not delete a stack variable, period. [Whether
WA_DeleteOnClosedocs 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 exactlyWA_DeleteOnClosedid, though I used it. -
@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.@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 you're right.
it's more sinister.
the QDialog implementation of delete on close is a
delete thiscall. 😱 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(); } -
@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) ?
-
@kshegunov
A "typo" is a misspelling, not a complete reversal of a comment's intention! :DAnd I agree it's about time somebody said you just must not delete a stack variable, period. [Whether
WA_DeleteOnClosedocs 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 exactlyWA_DeleteOnClosedid, though I used it.@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! ;)
Read and abide by the Qt Code of Conduct
-
@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! ;)
@kshegunov said in double free or corruption (out) when closing a QDialog with the WA_DeleteOnClose attribute set:
I added the comma
-
-
@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.@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_DeleteOnCloseactually does? One can guess it causes the call ofdeleteon 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 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_DeleteOnCloseactually does? One can guess it causes the call ofdeleteon 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.@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-enumIt'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 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-enumIt'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.
@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. -_-
-
@jsulm I don't think so. As you see the output "After exec" is not present. So the error occurs before leaving the scope..
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!
