Re: [Plplot-devel] qt_example memory management issues

[Alan W. I. <Ala...@gm...>]

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
__________________________