On 2018-12-31 11:44-0800 Alan W. Irwin wrote:
On 2018-12-31 11:28-0800 Alan W. Irwin wrote:[...] by the following temporary changes to qt_example: argc = 1; QApplication a( argc, argv ); // Must construct an instance of PlotWindow after QApplication. PlotWindow * win = new PlotWindow( Argc, Argv ); // Clean up Argv now that we are done with processing arguments. for ( int i = 0; i < Argc; ++i ) { delete[] Argv[i]; } delete[] Argv; delete win; return 0; So the QApplication never gets explicitly used in this experimental version of the code whose job is simply to test the PlotWindow constructor and destructor without actually using the PlotWindow instance for anything. An additional important part of these experiments is to make some changes to the destructor such as calling plend from there. And now I am going to test the effect of the Qt::WA_DeleteOnClose attribute as well.P.S. Something that just struck me is the above experimental code and also the normal version of this code create the "a" instance of QApplication on the stack. So that instance should automatically be deleted when the above code or the non-experimental version of this code return from qt_example main routine. So setting the above attribute seems like overkill and, in fact, might cause a double free. So at this stage I am hoping that not setting this attribute (as you tried in your own experiment) is the key step required in fixing the qt_example memory management. More later.
Hi António: A google search for "qapplication delete "WA_DeleteOnClose"" (without the outer quotes) showed what appeared to be mass confusion about deleting qApps, but one of those discussions <https://stackoverflow.com/questions/3153155/when-setting-the-wa-deleteonclose-attribute-on-a-qt-mainwindow-the-program-cras> does contain the following advice: "Remember that your main window destructor should run only once. That is to say that it should run either because of a stack unwind, or because of WA_DeleteOnClose, not both." The documentation at <http://doc.qt.io/qt-5/qt.html#WidgetAttribute-enum> of this attribute says the following: "Makes Qt delete this widget when the widget has accepted the close event (see QWidget::closeEvent())." which seems consistent with the advice. However, the only mentions of closeEvent in our entire code base are the following: software@merlin> find . -type f |grep -v .git |xargs grep closeEvent ./bindings/qt_gui/pyqt4/plplot_pyqt4.sip: void closeEvent(QCloseEvent *event); ./bindings/qt_gui/plqt.cpp:void QtPLWidget::closeEvent( QCloseEvent* event ) ./bindings/qt_gui/pyqt5/plplot_pyqt5.sip: void closeEvent(QCloseEvent *event); ./include/qt.h: void closeEvent( QCloseEvent* event ); So closeEvent is defined but never explicitly used in our code. So to help with my Qt education is this a case where closeEvent is essentially a callback that Qt demands must be defined and then it uses it internally for its own purposes (e.g., when a user closes a Qt GUI)? Regardless of your reply to that "Qt education question" it appears to me that to avoid double frees we must either drop this attribute or else create the qApp on the heap and not delete it explicitly. However, the above experimental code never gives the user the chance to close the GUI so closeEvent is likely never called and setting the attribute or not should make no difference for that experimental case. However, once I have figured out how to cleanly delete PlotWindow with the above experimental version of the code, then I plan to follow up by using that delete method in the non-experimental version of qt_example and look at valgrind results in that case (where setting the attribute would matter) with the qApp created on the stack (as in the original version of qt_example), and the above attribute dropped. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
