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
Re: [Plplot-devel] Testing of latest qt pushes requested
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. cheers, p.s I will have a look at your commit and test it on my own applications On Sun, Dec 30, 2018 at 9:58 PM Alan W. Irwin wrote: > Hi António: > > I have just pushed your change and my subsequent followup to make the > initQtApp and close QtApp code easier to read and more robust. > > Please look carefully at the code changes in my last commit > (plplot-5.14.0-15-g790754f35) and also test those changes to make sure > they work fine for your use case (qt applications using qt devices). > > Unless you find something that needs changing with that last commit, > that should complete our joint qt development work until you have > a chance to work on PLplot again in a couple of months. > > However, ideally it would be good to not have to wait that long for > the resolution of the occasional segfaults on exit for qt_example that > I encountered when comprehensive testing 5.14.0. So now that I > understand our qt device driver and binding a bit better, I am going > to look at that issue again. And if I can find a simple fix, I will > commit that, but if I still cannot find such a simple fix (as happened > during the 5.14.0 release because I am still in the early stages of > learning C++ and Qt), I will leave that (more complex?) fix to you in > a couple of months. > > 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 > __ > -- António Rodrigues Tomé Universidade da Beira Interior Instituto D. Luís (lab associado) email address: art...@gmail.com art...@ubi.pt http://www.researcherid.com/rid/A-5681-2013 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
