Re: [Plplot-devel] qt_example memory management issues (SOLVED!)
Hi António: Thanks for your recent replies concerning my Qt5 education and also your successful tests of the previous commit. With commit plplot-5.14.0-16-g02652c9a4 I am virtually positive from valgrind results that I have solved these qt_example memory management issues while still being able to properly delete the PLplot library and the PlotWindow instance. See that commit message for details. The comprehensive test for that commit did not turn up any segfaults for the first time ever! However, that test did turn up an intermittent hang for qt_example on exit similar to what I found in December for pyqt5_example (but no hang for pyqt5_example this time although that example is unchanged). But in this case, I could prove the hang was because the exec method for the qApp never returned control to the main routine of qt_example. See the commit message for documentation I discovered with a google search of the recommended signals and slots procedure for making the current problematic cleanup procedure completely robust and possibly solving these intermittent hang on exit problems I suspect this recommended and documented change is a matter of 15 minutes or so for someone who is expert in Qt5. But that is not me. (For example, I am just learned about Qt signals and slots today.) Of course, I am retired so I have much more time than the rest of the PLplot developers here to work on PLplot. So if you (or someone else here with Qt5 expertise) don't have time/inclination to fix this according to the web prescription I have documented, I do plan to do it myself after a substantial break to work on PLplot components that are a lot easier for me! 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
Re: [Plplot-devel] qt_example memory management issues
On Tue, Jan 1, 2019 at 10:09 PM Alan W. Irwin
wrote:
> 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
> 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)?
>
closeEvent is a protected function that is in qt_example case called when
you click in the X in the window application that closes/ends.
One may redefine it if needs extra actions to be performed before close the
window. Must of the times it is redefined to prompt to the user if he in
fact wants to close the window.
citing qt documentation
By default, the event is accepted and the widget is closed. You can
reimplement this function to change the way the widget responds to window
close requests. For example, you can prevent the window from closing by
calling ignore() on all events.
cheers
>
> 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
> Ep
Re: [Plplot-devel] qt_example memory management issues
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
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 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
Re: [Plplot-devel] qt_example memory management issues
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.
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
[Plplot-devel] qt_example memory management issues
On 2018-12-31 16:05- António Rodrigues Tomé wrote:
Hi Alan
let's do a small change in qt_example. cpp to make it more orthodox.
QApplication a( argc, argv );
PlotWindow win ( Argc, Argv );
win.show();
when I do this the program always crashes on close in my system.
much likely because there is an attempt to free twice a memory block.
It may result from
setAttribute( Qt::WA_DeleteOnClose );
on qt_Plotwindow.cpp as at destructor level qt may try to free something
that the driver has already free.
the fact is if I erase or comment that line the program does not crash
anymore on exit.
Hi António:
Thanks for these comments. In particular your remark on
setAttribute( Qt::WA_DeleteOnClose ) is likely to be quite
relevant to my experiments today.
Just to let you know where I am at the
moment, I have been looking carefully at PlotWindow since that class
is a part of qt_example (i.e., not part of the extqt device or the
PLplot qt binding). And since I am not that familiar with extqt, I
have been taking an experimental approach to learning about it
starting with figuring out all the ramifications of PlotWindow
construction and destruction 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.
For each such variant of the destructor I build the qt_example
target (which builds the qt_example application and all its PLplot
prerequisites) with the -g option for gcc and g++ and analyzed
run-time results using
valgrind --leak-check=full --show-leak-kinds=all --num-callers=500
examples/c++/qt_example >| valgrind.out 2>&1
The goal of these experiments is to implement a rock-solid destructor
for PlotWindow that leaves no memory directly allocated by PLplot that
continues to be allocated after PlotWindow destruction. I hasten to
add I am no where near that goal at the moment, but these experiments
are yielding a lot of data that I hope will help me to eventually reach
that goal.
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
