plplot-devel

[Plplot-devel] fixed memory leak plplot-5.10.0

[Norman G. <no...@te...>]

I noticed that at the end of plSelectDev(), in plcore.c,
a couple more fields of the PLStream
needed to be filled in (feedback from valgrind :-)),
so I added these two lines at line 3230:

     plsc->tidy = (void*) dispatch_table[dev - 1]->pl_tidy;
     plsc->tidy_data = (void*) plsc;

I expect the first line is correct for all devices.
I think the 2nd line is OK, too (I checked it is correct for
XWindows, the only device I am using)

Norm

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Alan W. I. <ir...@be...>]

@Andrew: There are some really interesting release implications here,
and if you feel Norman's fix (ideally in git am form as I have
requested from him below) or some other variant of it you like is a
no-brainer please go ahead and push it (see my further comment on the
release delay implications at the end.).

On 2015-03-17 20:28-0700 Norman Goldstein wrote:

> I noticed that at the end of plSelectDev(), in plcore.c,
> a couple more fields of the PLStream
> needed to be filled in (feedback from valgrind :-)),
> so I added these two lines at line 3230:
>
>     plsc->tidy = (void*) dispatch_table[dev - 1]->pl_tidy;
>     plsc->tidy_data = (void*) plsc;
>
> I expect the first line is correct for all devices.
> I think the 2nd line is OK, too (I checked it is correct for
> XWindows, the only device I am using)
>

Hi Norm:

As you are probably already aware, I plan to release a new version of
PLplot soon based on the git master tip version so your test of that
version (see access directions for master tip at
https://sourceforge.net/p/plplot/plplot/ci/master/tree/) would be much
appreciated.

Just to make sure we are on the same page, here is what I get for
master tip for dev psc
(using the CMake option -DBUILD_TEST=ON and following up with "make
all" to build all the necessary prerequisites first.

software@raven> valgrind examples/c/x00c -dev psc -o test.psc
==9610== Memcheck, a memory error detector
==9610== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==9610== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==9610== Command: examples/c/x00c -dev psc -o test.psc
==9610== 
==9610== 
==9610== HEAP SUMMARY:
==9610==     in use at exit: 0 bytes in 0 blocks
==9610==   total heap usage: 470 allocs, 470 frees, 132,943 bytes allocated
==9610== 
==9610== All heap blocks were freed -- no leaks are possible
==9610== 
==9610== For counts of detected and suppressed errors, rerun with: -v
==9610== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

i.e., perfect valgrind results.

And I also get perfect valgrind results for
software@raven> valgrind examples/c/x00c -dev svg -o test.svg

Note that both psc and svg are non-interactive devices that have no
external library dependencies.

In contrast, here are the -dev xwin results for the same (simple) example.

==9758== Memcheck, a memory error detector
==9758== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==9758== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==9758== Command: examples/c/x00c -dev xwin
==9758== 
==9758== 
==9758== HEAP SUMMARY:
==9758==     in use at exit: 42,535 bytes in 444 blocks
==9758==   total heap usage: 1,442 allocs, 998 frees, 434,710 bytes allocated
==9758== 
==9758== LEAK SUMMARY:
==9758==    definitely lost: 88 bytes in 1 blocks
==9758==    indirectly lost: 58 bytes in 2 blocks
==9758==      possibly lost: 0 bytes in 0 blocks
==9758==    still reachable: 42,389 bytes in 441 blocks
==9758==         suppressed: 0 bytes in 0 blocks
==9758== Rerun with --leak-check=full to see details of leaked memory
==9758== 
==9758== For counts of detected and suppressed errors, rerun with: -v
==9758== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

Do you also confirm this -dev xwin leak issue for master tip?

Assuming your answer is yes, does your above fix turn this into a
perfect valgrind result (again for master tip) without compromising
the perfect -dev svg and -dev psc results?

Also, if you have what you feel is a definitive fix, and you also have
some git knowledge could you send it here using the "git am" command
so we know exactly the change you want to make and so we can give you
proper credit for your work?

On the other hand, If you don't have a lot of git experience, we are
still happy to except your suggestion for a fix! Furthermore, if for
this case you decide you would like to gain some git experience, then
I would highly recommend you start by reading our README.developers
file (for master tip) which gives useful hints for our particular git
workflow.  We wrote that up from the perspective of git newbies (which
most of our active developers [including me] were when we started to
use git for Plplot development last summer).

@Andrew:

Although I am really anxious to get out the release, also note that if
Norman or you (based on his suggestions) find a definitive fix for
this particular plend-related issue for -dev xwin without compromising
our perfect -dev psc and -dev psc results, then I would be willing to
delay our release to test his fix (or your modification of same)
extensively for all our noninteractive and interactive devices. Also,
I assume you would be interested in doing such tests on your platforms
as well.  The fact is we currently have a lot of plend-related issues
for many of our interactive devices right now (and even a few
noninteractive devices) so if there is a fix that cleans up a
significant fraction of those issues for this release without causing
other problems, it would make me a happy man!

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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
__________________________

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Norman G. <no...@te...>]

I downloaded the latest source code:

git clone git://git.code.sf.net/p/plplot/plplot plplot.git

Confirmed the memory leak is still in this version.
(some headache, since the debug library did not get the "d' suffix)

The fix eliminates this memory leak, and no others originate in plplot.

Other tests:

-- svg tested fine
-- psc core dumped:

The psc core dump is happening because the ps-specific "tidy" is being
called twice, and the second time the output file is no longer valid.

I can look into this, but I wanted to give some feedback, first.
Let me know.

Cheer,
Norm

PS
I noticed  in file plcore.c, plSelectDev(), there is a "return" 
statement in the middle ,
so the assignment statements at the end of the method would not be executed
in this case.  So, I added the two new assignment statements also before the
"return" statement.

PPS What is the "fip" in "master fip", please?


On 03/18/2015 12:59 AM, Alan W. Irwin wrote:
> @Andrew: There are some really interesting release implications here,
> and if you feel Norman's fix (ideally in git am form as I have
> requested from him below) or some other variant of it you like is a
> no-brainer please go ahead and push it (see my further comment on the
> release delay implications at the end.).
>
> On 2015-03-17 20:28-0700 Norman Goldstein wrote:
>
>> I noticed that at the end of plSelectDev(), in plcore.c,
>> a couple more fields of the PLStream
>> needed to be filled in (feedback from valgrind :-)),
>> so I added these two lines at line 3230:
>>
>>     plsc->tidy = (void*) dispatch_table[dev - 1]->pl_tidy;
>>     plsc->tidy_data = (void*) plsc;
>>
>> I expect the first line is correct for all devices.
>> I think the 2nd line is OK, too (I checked it is correct for
>> XWindows, the only device I am using)
>>
>
> Hi Norm:
>
> As you are probably already aware, I plan to release a new version of
> PLplot soon based on the git master tip version so your test of that
> version (see access directions for master tip at
> https://sourceforge.net/p/plplot/plplot/ci/master/tree/) would be much
> appreciated.
>
> Just to make sure we are on the same page, here is what I get for
> master tip for dev psc
> (using the CMake option -DBUILD_TEST=ON and following up with "make
> all" to build all the necessary prerequisites first.
>
> software@raven> valgrind examples/c/x00c -dev psc -o test.psc
> ==9610== Memcheck, a memory error detector
> ==9610== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==9610== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright 
> info
> ==9610== Command: examples/c/x00c -dev psc -o test.psc
> ==9610== ==9610== ==9610== HEAP SUMMARY:
> ==9610==     in use at exit: 0 bytes in 0 blocks
> ==9610==   total heap usage: 470 allocs, 470 frees, 132,943 bytes 
> allocated
> ==9610== ==9610== All heap blocks were freed -- no leaks are possible
> ==9610== ==9610== For counts of detected and suppressed errors, rerun 
> with: -v
> ==9610== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
>
> i.e., perfect valgrind results.
>
> And I also get perfect valgrind results for
> software@raven> valgrind examples/c/x00c -dev svg -o test.svg
>
> Note that both psc and svg are non-interactive devices that have no
> external library dependencies.
>
> In contrast, here are the -dev xwin results for the same (simple) 
> example.
>
> ==9758== Memcheck, a memory error detector
> ==9758== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==9758== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright 
> info
> ==9758== Command: examples/c/x00c -dev xwin
> ==9758== ==9758== ==9758== HEAP SUMMARY:
> ==9758==     in use at exit: 42,535 bytes in 444 blocks
> ==9758==   total heap usage: 1,442 allocs, 998 frees, 434,710 bytes 
> allocated
> ==9758== ==9758== LEAK SUMMARY:
> ==9758==    definitely lost: 88 bytes in 1 blocks
> ==9758==    indirectly lost: 58 bytes in 2 blocks
> ==9758==      possibly lost: 0 bytes in 0 blocks
> ==9758==    still reachable: 42,389 bytes in 441 blocks
> ==9758==         suppressed: 0 bytes in 0 blocks
> ==9758== Rerun with --leak-check=full to see details of leaked memory
> ==9758== ==9758== For counts of detected and suppressed errors, rerun 
> with: -v
> ==9758== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
>
> Do you also confirm this -dev xwin leak issue for master tip?
>
> Assuming your answer is yes, does your above fix turn this into a
> perfect valgrind result (again for master tip) without compromising
> the perfect -dev svg and -dev psc results?
>
> Also, if you have what you feel is a definitive fix, and you also have
> some git knowledge could you send it here using the "git am" command
> so we know exactly the change you want to make and so we can give you
> proper credit for your work?
>
> On the other hand, If you don't have a lot of git experience, we are
> still happy to except your suggestion for a fix! Furthermore, if for
> this case you decide you would like to gain some git experience, then
> I would highly recommend you start by reading our README.developers
> file (for master tip) which gives useful hints for our particular git
> workflow.  We wrote that up from the perspective of git newbies (which
> most of our active developers [including me] were when we started to
> use git for Plplot development last summer).
>
> @Andrew:
>
> Although I am really anxious to get out the release, also note that if
> Norman or you (based on his suggestions) find a definitive fix for
> this particular plend-related issue for -dev xwin without compromising
> our perfect -dev psc and -dev psc results, then I would be willing to
> delay our release to test his fix (or your modification of same)
> extensively for all our noninteractive and interactive devices. Also,
> I assume you would be interested in doing such tests on your platforms
> as well.  The fact is we currently have a lot of plend-related issues
> for many of our interactive devices right now (and even a few
> noninteractive devices) so if there is a fix that cleans up a
> significant fraction of those issues for this release without causing
> other problems, it would make me a happy man!
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> 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
> __________________________
>

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Norman G. <no...@te...>]

It turns out the psc core dump was easy to fix:
Set the flag in the PLStream after closing the file
in ps.c .  The three tests were good:
xwin, psc and svg

So, I am ready to submit the updated
plcore.c  and  ps.c

Perhaps, though, other devices need a fix
similar to the ps.c, above.

Here is the output of git status:

 > git status | grep modified
         modified:   drivers/ps.c
         modified:   src/plcore.c

What are the comands for

git format
and
git am

to send the updates, please?

Norm


On 03/18/2015 09:59 AM, Norman Goldstein wrote:
> I downloaded the latest source code:
>
> git clone git://git.code.sf.net/p/plplot/plplot plplot.git
>
> Confirmed the memory leak is still in this version.
> (some headache, since the debug library did not get the "d' suffix)
>
> The fix eliminates this memory leak, and no others originate in plplot.
>
> Other tests:
>
> -- svg tested fine
> -- psc core dumped:
>
> The psc core dump is happening because the ps-specific "tidy" is being
> called twice, and the second time the output file is no longer valid.
>
> I can look into this, but I wanted to give some feedback, first.
> Let me know.
>
> Cheer,
> Norm
>
> PS
> I noticed  in file plcore.c, plSelectDev(), there is a "return"
> statement in the middle ,
> so the assignment statements at the end of the method would not be executed
> in this case.  So, I added the two new assignment statements also before the
> "return" statement.
>
> PPS What is the "fip" in "master fip", please?
>
>
> On 03/18/2015 12:59 AM, Alan W. Irwin wrote:
>> @Andrew: There are some really interesting release implications here,
>> and if you feel Norman's fix (ideally in git am form as I have
>> requested from him below) or some other variant of it you like is a
>> no-brainer please go ahead and push it (see my further comment on the
>> release delay implications at the end.).
>>
>> On 2015-03-17 20:28-0700 Norman Goldstein wrote:
>>
>>> I noticed that at the end of plSelectDev(), in plcore.c,
>>> a couple more fields of the PLStream
>>> needed to be filled in (feedback from valgrind :-)),
>>> so I added these two lines at line 3230:
>>>
>>>      plsc->tidy = (void*) dispatch_table[dev - 1]->pl_tidy;
>>>      plsc->tidy_data = (void*) plsc;
>>>
>>> I expect the first line is correct for all devices.
>>> I think the 2nd line is OK, too (I checked it is correct for
>>> XWindows, the only device I am using)
>>>
>> Hi Norm:
>>
>> As you are probably already aware, I plan to release a new version of
>> PLplot soon based on the git master tip version so your test of that
>> version (see access directions for master tip at
>> https://sourceforge.net/p/plplot/plplot/ci/master/tree/) would be much
>> appreciated.
>>
>> Just to make sure we are on the same page, here is what I get for
>> master tip for dev psc
>> (using the CMake option -DBUILD_TEST=ON and following up with "make
>> all" to build all the necessary prerequisites first.
>>
>> software@raven> valgrind examples/c/x00c -dev psc -o test.psc
>> ==9610== Memcheck, a memory error detector
>> ==9610== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
>> ==9610== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright
>> info
>> ==9610== Command: examples/c/x00c -dev psc -o test.psc
>> ==9610== ==9610== ==9610== HEAP SUMMARY:
>> ==9610==     in use at exit: 0 bytes in 0 blocks
>> ==9610==   total heap usage: 470 allocs, 470 frees, 132,943 bytes
>> allocated
>> ==9610== ==9610== All heap blocks were freed -- no leaks are possible
>> ==9610== ==9610== For counts of detected and suppressed errors, rerun
>> with: -v
>> ==9610== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
>>
>> i.e., perfect valgrind results.
>>
>> And I also get perfect valgrind results for
>> software@raven> valgrind examples/c/x00c -dev svg -o test.svg
>>
>> Note that both psc and svg are non-interactive devices that have no
>> external library dependencies.
>>
>> In contrast, here are the -dev xwin results for the same (simple)
>> example.
>>
>> ==9758== Memcheck, a memory error detector
>> ==9758== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
>> ==9758== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright
>> info
>> ==9758== Command: examples/c/x00c -dev xwin
>> ==9758== ==9758== ==9758== HEAP SUMMARY:
>> ==9758==     in use at exit: 42,535 bytes in 444 blocks
>> ==9758==   total heap usage: 1,442 allocs, 998 frees, 434,710 bytes
>> allocated
>> ==9758== ==9758== LEAK SUMMARY:
>> ==9758==    definitely lost: 88 bytes in 1 blocks
>> ==9758==    indirectly lost: 58 bytes in 2 blocks
>> ==9758==      possibly lost: 0 bytes in 0 blocks
>> ==9758==    still reachable: 42,389 bytes in 441 blocks
>> ==9758==         suppressed: 0 bytes in 0 blocks
>> ==9758== Rerun with --leak-check=full to see details of leaked memory
>> ==9758== ==9758== For counts of detected and suppressed errors, rerun
>> with: -v
>> ==9758== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
>>
>> Do you also confirm this -dev xwin leak issue for master tip?
>>
>> Assuming your answer is yes, does your above fix turn this into a
>> perfect valgrind result (again for master tip) without compromising
>> the perfect -dev svg and -dev psc results?
>>
>> Also, if you have what you feel is a definitive fix, and you also have
>> some git knowledge could you send it here using the "git am" command
>> so we know exactly the change you want to make and so we can give you
>> proper credit for your work?
>>
>> On the other hand, If you don't have a lot of git experience, we are
>> still happy to except your suggestion for a fix! Furthermore, if for
>> this case you decide you would like to gain some git experience, then
>> I would highly recommend you start by reading our README.developers
>> file (for master tip) which gives useful hints for our particular git
>> workflow.  We wrote that up from the perspective of git newbies (which
>> most of our active developers [including me] were when we started to
>> use git for Plplot development last summer).
>>
>> @Andrew:
>>
>> Although I am really anxious to get out the release, also note that if
>> Norman or you (based on his suggestions) find a definitive fix for
>> this particular plend-related issue for -dev xwin without compromising
>> our perfect -dev psc and -dev psc results, then I would be willing to
>> delay our release to test his fix (or your modification of same)
>> extensively for all our noninteractive and interactive devices. Also,
>> I assume you would be interested in doing such tests on your platforms
>> as well.  The fact is we currently have a lot of plend-related issues
>> for many of our interactive devices right now (and even a few
>> noninteractive devices) so if there is a fix that cleans up a
>> significant fraction of those issues for this release without causing
>> other problems, it would make me a happy man!
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> Astronomical research affiliation with Department of Physics and
>> Astronomy,
>> University of Victoria (astrowww.phys.uvic.ca).
>>
>> 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
>> __________________________
>>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Alan W. I. <ir...@be...>]

On 2015-03-18 11:05-0700 Norman Goldstein wrote:

> It turns out the psc core dump was easy to fix:
> Set the flag in the PLStream after closing the file
> in ps.c .  The three tests were good:
> xwin, psc and svg
>
> So, I am ready to submit the updated
> plcore.c  and  ps.c
>
> Perhaps, though, other devices need a fix
> similar to the ps.c, above.
>
> Here is the output of git status:
>
>> git status | grep modified
>        modified:   drivers/ps.c
>        modified:   src/plcore.c
>
> What are the comands for
>
> git format
> and
> git am
>
> to send the updates, please?

First, follow the advice in README.developers about working on
a topic branch.  Then checkout that topic branch, and use
git commit --all to create a commit on that topic branch with
the files that are modified above.

Then you use "git format-patch" to create the patch series (which
in this case will be just one patch) that we need to look at with
"git am" on our end.  For help with any git command, try

git help <commandname>

in this case <commandname> is format-patch, and that git help
command was how I learned to use "git format-patch" recently.

Also, before sending it to this list as an attachment, look at the
file produced by git format-patch to make sure it has just the changes
in it that you want and nothing else.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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] new plplot version and wxWidgets

[laurent B. <Lau...@un...>]

Today i have try to use new plplot version for my wxwidgets application. 
With 5.10.0 plplot I can use plplot to draw a curve in a panel and a box 
sizer (attached image). My class was something like this :
Histogram::Histogram(  wxWindow* parent, wxWindowID id, const wxPoint& pos,
                             const wxSize& size, long style, int 
pl_style ) :
           wxPLplotwindow( parent, id, pos, size, style, pl_style )
With the new plplot version how can I do the same thing?

Thanks for yours answers

Re: [Plplot-devel] new plplot version and wxWidgets

[Phil R. <p.d...@gm...>]

Hello Laurent
The equivalent code to create a plot on a wxWindow would now be something like

wxPLplotwindow<wxPanel> *myPlotWindow = new wxPLplotwindow<wxPanel>();
myPlotWindow->Create( parent, id, pos, size, style, name );

Note that you can replace wxPanel, with any other type of wxWindow for
which we can get a wxPaintDC, so it could be a wxFrame, a
wxMDIClientWindow or even a wxButton I think.

If you look at wxPlplotDemo.cpp then you can see the creation of a
simple wxPLplotwindow<wxFrame>. Or if you look at wxplframe.cpp you
can see a more complicated example where we create a wxPLFrame class
which inherits from wxPLplotwindow<wxFrame>. If you do this then you
can have one line construction as in your code.

Note that pl_style has been removed and replaced with a bool to
specify using either a wxGCDC or a wxMemoryDC for the rendering. This
is because the various backends (wxGraphicsContext, wxDC and AGG) have
been removed and replaced with a single backend and FreeType support
has been removed too.

Feedback very much appreciated. If you find that there are any
problems or issues or difficulties please let me know.

Phil

On 18 March 2015 at 21:26, laurent Berger <Lau...@un...> wrote:
> Today i have try to use new plplot version for my wxwidgets application.
> With 5.10.0 plplot I can use plplot to draw a curve in a panel and a box
> sizer (attached image). My class was something like this :
> Histogram::Histogram(  wxWindow* parent, wxWindowID id, const wxPoint& pos,
>                             const wxSize& size, long style, int pl_style ) :
>           wxPLplotwindow( parent, id, pos, size, style, pl_style )
> With the new plplot version how can I do the same thing?
>
> Thanks for yours answers
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] new plplot version and wxWidgets

[Alan W. I. <ir...@be...>]

On 2015-03-18 22:26+0100 laurent Berger wrote:

> Today i have try to use new plplot version for my wxwidgets application. With 
> 5.10.0 plplot I can use plplot to draw a curve in a panel and a box sizer 
> (attached image). My class was something like this :
> Histogram::Histogram(  wxWindow* parent, wxWindowID id, const wxPoint& pos,
>                            const wxSize& size, long style, int pl_style ) :
>          wxPLplotwindow( parent, id, pos, size, style, pl_style )
> With the new plplot version how can I do the same thing?
>
> Thanks for yours answers

For the master tip version I would suggest comparing
deprecated_wxPLplotDemo.cpp (the old way of doing things)
with wxPLplotDemo.cpp (the new way of doing things) to
help give you a hint on what you have to change in your
own wxwidgets apps.

By the way, it is not working correctly just yet, but for the release
we plan to provide a -DOLD_WXWIDGETS=ON option (OFF will be the
default) where the user can select the old way of using wxwidgets
which should mostly just work (including using
deprecated_wxPLplotDemo.cpp rather than wxPLplotDemo.cpp to create the
wxPLplotDemo app.) But don't rely on OLD_WXWIDGETS=ON too much because
we plan to deprecate it for the next release and then remove this
option altogether in some future release.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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
__________________________

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Alan W. I. <ir...@be...>]

On 2015-03-18 09:59-0700 Norman Goldstein wrote:

> I downloaded the latest source code:
>
> git clone git://git.code.sf.net/p/plplot/plplot plplot.git
>
> Confirmed the memory leak is still in this version.
> (some headache, since the debug library did not get the "d' suffix)

Yes, we are dropping the d suffix, see README.release for master tip
for why.

>
> The fix eliminates this memory leak, and no others originate in plplot.
>
> Other tests:
>
> -- svg tested fine
> -- psc core dumped:
>
> The psc core dump is happening because the ps-specific "tidy" is being
> called twice, and the second time the output file is no longer valid.
>
> I can look into this, but I wanted to give some feedback, first.
> Let me know.
>
> Cheer,
> Norm
>
> PS
> I noticed  in file plcore.c, plSelectDev(), there is a "return" statement in 
> the middle ,
> so the assignment statements at the end of the method would not be executed
> in this case.  So, I added the two new assignment statements also before the
> "return" statement.
>
> PPS What is the "fip" in "master fip", please?

A typo.  master fip ==> master tip.  :-)

And thanks for the information on the ps device driver problem with
your fix which implies this fix is going to be more complex than first
thought.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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
__________________________

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Andrew R. <and...@us...>]

On Wed, Mar 18, 2015 at 12:59:18AM -0700, Alan Irwin wrote:
> @Andrew: There are some really interesting release implications here,
> and if you feel Norman's fix (ideally in git am form as I have
> requested from him below) or some other variant of it you like is a
> no-brainer please go ahead and push it (see my further comment on the
> release delay implications at the end.).

Norman,

I'm not sure I agree with your patch here in general. I've tested it on
Linux and it makes no difference to my valgrind results. Further, adding
in some debugging statements shows that at the point you set plsc->tidy
the dispatch table entry is NULL anyway so your code makes no difference.
This is with dynamic drivers. Are you using static drivers? In that case
things may be different and we need to investigate more closely.

Also, looking at the code in plP_tidy, the tidy function
dispatch_table[dev - 1]->pl_tidy should already be called. Again debugging
statements show this is the case, so I can well see why you end up with a
double call for the psc driver if your change was having an effect. 

Can you confirm the build options you are using for plplot, and also the
precise way you ran valgrind to generate this feedback. Since I'm unable
to reproduce your results I'm a bit confused at precisely what the memory
issue is.

Thanks

Andrew

> 
> On 2015-03-17 20:28-0700 Norman Goldstein wrote:
> 
> > I noticed that at the end of plSelectDev(), in plcore.c,
> > a couple more fields of the PLStream
> > needed to be filled in (feedback from valgrind :-)),
> > so I added these two lines at line 3230:
> >
> >     plsc->tidy = (void*) dispatch_table[dev - 1]->pl_tidy;
> >     plsc->tidy_data = (void*) plsc;
> >
> > I expect the first line is correct for all devices.
> > I think the 2nd line is OK, too (I checked it is correct for
> > XWindows, the only device I am using)
> >
> 
> Hi Norm:
> 
> As you are probably already aware, I plan to release a new version of
> PLplot soon based on the git master tip version so your test of that
> version (see access directions for master tip at
> https://sourceforge.net/p/plplot/plplot/ci/master/tree/) would be much
> appreciated.
> 
> Just to make sure we are on the same page, here is what I get for
> master tip for dev psc
> (using the CMake option -DBUILD_TEST=ON and following up with "make
> all" to build all the necessary prerequisites first.
> 
> software@raven> valgrind examples/c/x00c -dev psc -o test.psc
> ==9610== Memcheck, a memory error detector
> ==9610== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==9610== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==9610== Command: examples/c/x00c -dev psc -o test.psc
> ==9610== 
> ==9610== 
> ==9610== HEAP SUMMARY:
> ==9610==     in use at exit: 0 bytes in 0 blocks
> ==9610==   total heap usage: 470 allocs, 470 frees, 132,943 bytes allocated
> ==9610== 
> ==9610== All heap blocks were freed -- no leaks are possible
> ==9610== 
> ==9610== For counts of detected and suppressed errors, rerun with: -v
> ==9610== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
> 
> i.e., perfect valgrind results.
> 
> And I also get perfect valgrind results for
> software@raven> valgrind examples/c/x00c -dev svg -o test.svg
> 
> Note that both psc and svg are non-interactive devices that have no
> external library dependencies.
> 
> In contrast, here are the -dev xwin results for the same (simple) example.
> 
> ==9758== Memcheck, a memory error detector
> ==9758== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==9758== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==9758== Command: examples/c/x00c -dev xwin
> ==9758== 
> ==9758== 
> ==9758== HEAP SUMMARY:
> ==9758==     in use at exit: 42,535 bytes in 444 blocks
> ==9758==   total heap usage: 1,442 allocs, 998 frees, 434,710 bytes allocated
> ==9758== 
> ==9758== LEAK SUMMARY:
> ==9758==    definitely lost: 88 bytes in 1 blocks
> ==9758==    indirectly lost: 58 bytes in 2 blocks
> ==9758==      possibly lost: 0 bytes in 0 blocks
> ==9758==    still reachable: 42,389 bytes in 441 blocks
> ==9758==         suppressed: 0 bytes in 0 blocks
> ==9758== Rerun with --leak-check=full to see details of leaked memory
> ==9758== 
> ==9758== For counts of detected and suppressed errors, rerun with: -v
> ==9758== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
> 
> Do you also confirm this -dev xwin leak issue for master tip?
> 
> Assuming your answer is yes, does your above fix turn this into a
> perfect valgrind result (again for master tip) without compromising
> the perfect -dev svg and -dev psc results?
> 
> Also, if you have what you feel is a definitive fix, and you also have
> some git knowledge could you send it here using the "git am" command
> so we know exactly the change you want to make and so we can give you
> proper credit for your work?
> 
> On the other hand, If you don't have a lot of git experience, we are
> still happy to except your suggestion for a fix! Furthermore, if for
> this case you decide you would like to gain some git experience, then
> I would highly recommend you start by reading our README.developers
> file (for master tip) which gives useful hints for our particular git
> workflow.  We wrote that up from the perspective of git newbies (which
> most of our active developers [including me] were when we started to
> use git for Plplot development last summer).
> 
> @Andrew:
> 
> Although I am really anxious to get out the release, also note that if
> Norman or you (based on his suggestions) find a definitive fix for
> this particular plend-related issue for -dev xwin without compromising
> our perfect -dev psc and -dev psc results, then I would be willing to
> delay our release to test his fix (or your modification of same)
> extensively for all our noninteractive and interactive devices. Also,
> I assume you would be interested in doing such tests on your platforms
> as well.  The fact is we currently have a lot of plend-related issues
> for many of our interactive devices right now (and even a few
> noninteractive devices) so if there is a fix that cleans up a
> significant fraction of those issues for this release without causing
> other problems, it would make me a happy man!
> 
> Alan
> __________________________
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> 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
> __________________________
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Andrew R. <and...@us...>]

On Wed, Mar 18, 2015 at 10:57:33PM +0000, Andrew Ross wrote:
> On Wed, Mar 18, 2015 at 12:59:18AM -0700, Alan Irwin wrote:
> > @Andrew: There are some really interesting release implications here,
> > and if you feel Norman's fix (ideally in git am form as I have
> > requested from him below) or some other variant of it you like is a
> > no-brainer please go ahead and push it (see my further comment on the
> > release delay implications at the end.).
> 
> Norman,
> 
> I'm not sure I agree with your patch here in general. I've tested it on
> Linux and it makes no difference to my valgrind results. Further, adding
> in some debugging statements shows that at the point you set plsc->tidy
> the dispatch table entry is NULL anyway so your code makes no difference.
> This is with dynamic drivers. Are you using static drivers? In that case
> things may be different and we need to investigate more closely.
> 
> Also, looking at the code in plP_tidy, the tidy function
> dispatch_table[dev - 1]->pl_tidy should already be called. Again debugging
> statements show this is the case, so I can well see why you end up with a
> double call for the psc driver if your change was having an effect. 
> 
> Can you confirm the build options you are using for plplot, and also the
> precise way you ran valgrind to generate this feedback. Since I'm unable
> to reproduce your results I'm a bit confused at precisely what the memory
> issue is.
> 

OK. To follow up my own post I think I now know what is going wrong. You
fix is definitely wrong, because if you do compile without dynamic drivers
then your code results in a double call to the tidy function. I was
exiting the examples using return or 'Q', which results in stream_closed
being set to 0 so the tidy function is called. If you exit by pressing the
close button at the top of the xwin window however, then stream_closed = 1
and so the tidy function is not called. This results in an additional memory 
leak. I'll have a look how to fix that.

Norman, can you confirm that my interpretation of what you are doing is
correct?

Thanks

Andrew

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Andrew R. <and...@us...>]

On Wed, Mar 18, 2015 at 11:10:20PM +0000, Andrew Ross wrote:
> On Wed, Mar 18, 2015 at 10:57:33PM +0000, Andrew Ross wrote:
> > On Wed, Mar 18, 2015 at 12:59:18AM -0700, Alan Irwin wrote:
> > > @Andrew: There are some really interesting release implications here,
> > > and if you feel Norman's fix (ideally in git am form as I have
> > > requested from him below) or some other variant of it you like is a
> > > no-brainer please go ahead and push it (see my further comment on the
> > > release delay implications at the end.).
> > 
> > Norman,
> > 
> > I'm not sure I agree with your patch here in general. I've tested it on
> > Linux and it makes no difference to my valgrind results. Further, adding
> > in some debugging statements shows that at the point you set plsc->tidy
> > the dispatch table entry is NULL anyway so your code makes no difference.
> > This is with dynamic drivers. Are you using static drivers? In that case
> > things may be different and we need to investigate more closely.
> > 
> > Also, looking at the code in plP_tidy, the tidy function
> > dispatch_table[dev - 1]->pl_tidy should already be called. Again debugging
> > statements show this is the case, so I can well see why you end up with a
> > double call for the psc driver if your change was having an effect. 
> > 
> > Can you confirm the build options you are using for plplot, and also the
> > precise way you ran valgrind to generate this feedback. Since I'm unable
> > to reproduce your results I'm a bit confused at precisely what the memory
> > issue is.
> > 
> 
> OK. To follow up my own post I think I now know what is going wrong. You
> fix is definitely wrong, because if you do compile without dynamic drivers
> then your code results in a double call to the tidy function. I was
> exiting the examples using return or 'Q', which results in stream_closed
> being set to 0 so the tidy function is called. If you exit by pressing the
> close button at the top of the xwin window however, then stream_closed = 1
> and so the tidy function is not called. This results in an additional memory 
> leak. I'll have a look how to fix that.
> 
> Norman, can you confirm that my interpretation of what you are doing is
> correct?

The attached patch fixes the memory leak for me. Pressing the close button
should now behave the same as pressing 'Q', i.e. it will abort the
program and clean up correctly. It looks like this was changed at some
stage in the past, but I don't know why. I guess this would allow a
programme to continue, and to potentially reopen a new xwin window. If we
want to retain this functionality it will require a bit more thinking
about. 

The relevant commit is

commit 9961465cb7b90c07c216f1a708b67d7a65753e11
Author: Hazen Babcock <hba...@us...>
Date:   Mon May 31 00:46:56 2010 +0000

    Change xwin driver to not call plexit() when the window is closed by
clicking on the close box. Instead all subsequent plotting commands sent
to the stream are ignored.
    
    svn path=/trunk/; revision=11041

I'm a little uneasy about applying this patch so late in the release cycle
in case there are any unforseen consequences. The current situation will
result in a memory leak when closing the window with the button, but since
this is on exit anyway it should not be too serious. 

Andrew

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Alan W. I. <ir...@be...>]

On 2015-03-18 23:39-0000 Andrew Ross wrote:

> I'm a little uneasy about applying this patch so late in the release cycle
> in case there are any unforseen consequences. The current situation will
> result in a memory leak when closing the window with the button, but since
> this is on exit anyway it should not be too serious.

OK, Andrew. If you are uneasy about even this small a patch let's
leave it for now and consider what to do about all the plend issues we
currently have for a variety of device drivers after the release.

Thanks for looking at this particular xwin plend issue.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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
__________________________

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Norman G. <no...@te...>]

Sorry, I just got back in ...
OK, I certainly bow to your more extensive insight to the plplot big 
picture.
For the record, here is how I configured plolot:

cmake -DENABLE_ocaml=OFF -DCMAKE_BUILD_TYPE=Debug. -DBUILD_TEST=ON  .

Attached, is the cmake log.
I see that the default is    ENABLE_DYNDRIVERS:    OFF

I disabled ocaml to avoid circular soft-linking that was breaking the build.
  I ran examples/c++/x00.cpp  to do my testing, for xw, psc and svg, for 
the
two cases of interactively typing in the device number, and of supplying
the -dev swtich on the command line.

When I was first running on the downloaded code, I set a breakpoint
on plD_tidy_xw, and it was never hit.  That is what started me going
down the path I took.  Here are the results of "make test", that I just
ran on my patched branch:

Running tests...
Test project /home/transient/systems/PLPLOT/plplot.git
       Start  1: examples_c
  1/18 Test  #1: examples_c .......................   Passed 14.57 sec
       Start  2: examples_cxx
  2/18 Test  #2: examples_cxx .....................   Passed 14.87 sec
       Start  3: examples_f95
  3/18 Test  #3: examples_f95 .....................   Passed 5.13 sec
       Start  4: examples_octave
  4/18 Test  #4: examples_octave ..................   Passed 7.60 sec
       Start  5: examples_python
  5/18 Test  #5: examples_python ..................   Passed 19.39 sec
       Start  6: examples_svg
  6/18 Test  #6: examples_svg .....................   Passed 16.68 sec
       Start  7: examples_pscairo
  7/18 Test  #7: examples_pscairo .................***Failed 0.20 sec
       Start  8: examples_pngcairo
  8/18 Test  #8: examples_pngcairo ................***Failed 0.09 sec
       Start  9: examples_xfig
*** Error in 
`/home/transient/systems/PLPLOT/plplot.git/examples/c/x00c': double free 
or corruption (!prev): 0x0000000001e0d500 **
...... Lots of lines------------------
  9/18 Test  #9: examples_xfig ....................***Failed 0.05 sec
       Start 10: examples_bmpqt
10/18 Test #10: examples_bmpqt ...................***Failed 0.89 sec
       Start 11: examples_jpgqt
11/18 Test #11: examples_jpgqt ...................***Failed 0.49 sec
       Start 12: examples_pngqt
12/18 Test #12: examples_pngqt ...................***Failed 0.62 sec
       Start 13: examples_ppmqt
13/18 Test #13: examples_ppmqt ...................***Failed 0.61 sec
       Start 14: examples_tiffqt
14/18 Test #14: examples_tiffqt ..................***Failed 0.51 sec
       Start 15: examples_svgqt
15/18 Test #15: examples_svgqt ...................***Failed 0.53 sec
       Start 16: examples_epsqt
16/18 Test #16: examples_epsqt ...................***Failed 0.62 sec
       Start 17: examples_pdfqt
17/18 Test #17: examples_pdfqt ...................***Failed 0.57 sec
       Start 18: examples_compare
18/18 Test #18: examples_compare .................   Passed 0.27 sec

39% tests passed, 11 tests failed out of 18

Total Test time (real) =  83.71 sec
The following tests FAILED:
           7 - examples_pscairo (Failed)
           8 - examples_pngcairo (Failed)
           9 - examples_xfig (Failed)
          10 - examples_bmpqt (Failed)
          11 - examples_jpgqt (Failed)
          12 - examples_pngqt (Failed)
          13 - examples_ppmqt (Failed)
          14 - examples_tiffqt (Failed)
          15 - examples_svgqt (Failed)
          16 - examples_epsqt (Failed)
          17 - examples_pdfqt (Failed)

Cheers,
Norm

On 03/18/2015 07:15 PM, Alan W. Irwin wrote:
> On 2015-03-18 23:39-0000 Andrew Ross wrote:
>
>> I'm a little uneasy about applying this patch so late in the release 
>> cycle
>> in case there are any unforseen consequences. The current situation will
>> result in a memory leak when closing the window with the button, but 
>> since
>> this is on exit anyway it should not be too serious.
>
> OK, Andrew. If you are uneasy about even this small a patch let's
> leave it for now and consider what to do about all the plend issues we
> currently have for a variety of device drivers after the release.
>
> Thanks for looking at this particular xwin plend issue.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> 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
> __________________________
>

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Andrew R. <and...@us...>]

Norman,

Thanks. This confirms that you are not using dynamic drivers. This
explains why your fix works for you and coincides with my experiments.
Just one further confirmation - were you closing the plplot window using
the close button (X) on the window, or by pressing return / 'Q'?

Your testing is really useful here since there are lots of different build
options / paths through the code, even for simple examples. We have a
pretty comprehensive set of tests, but it is hard for us to cover
everything. For example, when running the interactive tests I always use
return to move on to the next page so I'd not spotted this bug before.
You've definitely highlighted one xwin driver bug - I just need to work
out the best way to fix it. I just want to be sure there is nothing else
lurking behind it.

Thanks

Andrew

On Wed, Mar 18, 2015 at 09:20:29PM -0700, Norman Goldstein wrote:
> Sorry, I just got back in ...
> OK, I certainly bow to your more extensive insight to the plplot big
> picture.
> For the record, here is how I configured plolot:
> 
> cmake -DENABLE_ocaml=OFF -DCMAKE_BUILD_TYPE=Debug. -DBUILD_TEST=ON  .
> 
> Attached, is the cmake log.
> I see that the default is    ENABLE_DYNDRIVERS:    OFF
> 
> I disabled ocaml to avoid circular soft-linking that was breaking the build.
>  I ran examples/c++/x00.cpp  to do my testing, for xw, psc and svg, for the
> two cases of interactively typing in the device number, and of supplying
> the -dev swtich on the command line.
> 
> When I was first running on the downloaded code, I set a breakpoint
> on plD_tidy_xw, and it was never hit.  That is what started me going
> down the path I took.  Here are the results of "make test", that I just
> ran on my patched branch:
> 
> Running tests...
> Test project /home/transient/systems/PLPLOT/plplot.git
>       Start  1: examples_c
>  1/18 Test  #1: examples_c .......................   Passed 14.57 sec
>       Start  2: examples_cxx
>  2/18 Test  #2: examples_cxx .....................   Passed 14.87 sec
>       Start  3: examples_f95
>  3/18 Test  #3: examples_f95 .....................   Passed 5.13 sec
>       Start  4: examples_octave
>  4/18 Test  #4: examples_octave ..................   Passed 7.60 sec
>       Start  5: examples_python
>  5/18 Test  #5: examples_python ..................   Passed 19.39 sec
>       Start  6: examples_svg
>  6/18 Test  #6: examples_svg .....................   Passed 16.68 sec
>       Start  7: examples_pscairo
>  7/18 Test  #7: examples_pscairo .................***Failed 0.20 sec
>       Start  8: examples_pngcairo
>  8/18 Test  #8: examples_pngcairo ................***Failed 0.09 sec
>       Start  9: examples_xfig
> *** Error in `/home/transient/systems/PLPLOT/plplot.git/examples/c/x00c':
> double free or corruption (!prev): 0x0000000001e0d500 **
> ...... Lots of lines------------------
>  9/18 Test  #9: examples_xfig ....................***Failed 0.05 sec
>       Start 10: examples_bmpqt
> 10/18 Test #10: examples_bmpqt ...................***Failed 0.89 sec
>       Start 11: examples_jpgqt
> 11/18 Test #11: examples_jpgqt ...................***Failed 0.49 sec
>       Start 12: examples_pngqt
> 12/18 Test #12: examples_pngqt ...................***Failed 0.62 sec
>       Start 13: examples_ppmqt
> 13/18 Test #13: examples_ppmqt ...................***Failed 0.61 sec
>       Start 14: examples_tiffqt
> 14/18 Test #14: examples_tiffqt ..................***Failed 0.51 sec
>       Start 15: examples_svgqt
> 15/18 Test #15: examples_svgqt ...................***Failed 0.53 sec
>       Start 16: examples_epsqt
> 16/18 Test #16: examples_epsqt ...................***Failed 0.62 sec
>       Start 17: examples_pdfqt
> 17/18 Test #17: examples_pdfqt ...................***Failed 0.57 sec
>       Start 18: examples_compare
> 18/18 Test #18: examples_compare .................   Passed 0.27 sec
> 
> 39% tests passed, 11 tests failed out of 18
> 
> Total Test time (real) =  83.71 sec
> The following tests FAILED:
>           7 - examples_pscairo (Failed)
>           8 - examples_pngcairo (Failed)
>           9 - examples_xfig (Failed)
>          10 - examples_bmpqt (Failed)
>          11 - examples_jpgqt (Failed)
>          12 - examples_pngqt (Failed)
>          13 - examples_ppmqt (Failed)
>          14 - examples_tiffqt (Failed)
>          15 - examples_svgqt (Failed)
>          16 - examples_epsqt (Failed)
>          17 - examples_pdfqt (Failed)
> 
> Cheers,
> Norm
> 
> On 03/18/2015 07:15 PM, Alan W. Irwin wrote:
> >On 2015-03-18 23:39-0000 Andrew Ross wrote:
> >
> >>I'm a little uneasy about applying this patch so late in the release
> >>cycle
> >>in case there are any unforseen consequences. The current situation will
> >>result in a memory leak when closing the window with the button, but
> >>since
> >>this is on exit anyway it should not be too serious.
> >
> >OK, Andrew. If you are uneasy about even this small a patch let's
> >leave it for now and consider what to do about all the plend issues we
> >currently have for a variety of device drivers after the release.
> >
> >Thanks for looking at this particular xwin plend issue.
> >
> >Alan
> >__________________________
> >Alan W. Irwin
> >
> >Astronomical research affiliation with Department of Physics and
> >Astronomy,
> >University of Victoria (astrowww.phys.uvic.ca).
> >
> >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
> >__________________________
> >
> 

> -- Explicitly setting policy CMP0022 to OLD
> -- Explicitly setting policy CMP0023 to OLD
> -- CMake version = 2.8.12.2
> -- CMAKE_SYSTEM_NAME = Linux
> -- SH_EXECUTABLE = /usr/bin/bash
> -- Checking whether system has ANSI C header files
> -- ANSI C header files - found
> -- SWIG_VERSION = 2.0.11
> -- Looking for pkg-config - found
> -- X11_FOUND = 1
> -- X11_INCLUDE_DIR = /usr/include
> -- X11_COMPILE_FLAGS = -I/usr/include
> -- X11_LIBRARIES = /usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so
> -- NOTICE: Found: /usr/bin/gfortran
> -- PYTHON_VERSION = 2.7.5
> -- Building Python binding with plsmem() support
> -- OCTAVE = /usr/bin/octave
> -- MKOCTFILE = /usr/bin/mkoctfile
> -- OCTAVE_CONFIG = /usr/bin/octave-config
> -- OCTAVE_VERSION = 3.6.4
> -- OCTAVE_LIBRARIES = /usr/lib64/octave/3.6.4/liboctave.so
> -- OCTINTERP_LIBRARIES = /usr/lib64/octave/3.6.4/liboctinterp.so
> -- OCTAVE_INCLUDE_PATH = /usr/include;/usr/include/octave-3.6.4;/usr/include/octave-3.6.4/octave
> -- PLPLOT_OCTAVE_DIR = /usr/local/share/plplot_octave
> -- OCTAVE_M_DIR = /usr/local/share/octave/site/m
> -- OCTAVE_OCT_DIR = /usr/local/lib/octave
> -- WARNING: ENABLE_tcl is OFF so disabling everything else that is Tcl/Tk related
> -- FindShapelib: Found shapelib header directory, /usr/include, and library, /usr/lib64/libshp.so.
> -- FindQHull: Found both qhull_a.h and libqhull.a
> -- QHULL_INCLUDE_DIRS = /usr/include
> -- QHULL_LIBRARIES = /usr/lib64/libqhull.so
> -- QHULL_RPATH = 
> -- checking for module 'pango'
> --   found pango, version 1.36.1
> -- checking for module 'pangoft2'
> --   found pangoft2, version 1.36.1
> -- checking for module 'pangocairo'
> --   found pangocairo, version 1.36.1
> -- TKLIB_COMPILE_FLAGS = -I"TK_INCLUDE_PATH-NOTFOUND"
> -- NP_QT_COMPILE_DEFINITIONS = QT_SVG_LIB;QT_GUI_LIB;QT_CORE_LIB
> -- QT_COMPILE_DEFINITIONS = -DQT_SVG_LIB;-DQT_GUI_LIB;-DQT_CORE_LIB
> -- NP_QT_INCLUDE_DIRECTORIES = /usr/include;/usr/include/QtSvg;/usr/include/QtGui;/usr/include/QtCore
> -- QT_INCLUDE_DIRECTORIES = -isystem /usr/include;-isystem /usr/include/QtSvg;-isystem /usr/include/QtGui;-isystem /usr/include/QtCore
> -- pc_qt_COMPILE_FLAGS = -I/usr/include -I/usr/include/QtSvg -I/usr/include/QtGui -I/usr/include/QtCore
> -- wxWidgets found
> -- wxwidgets_COMPILE_FLAGS = -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ 
> -- wxwidgets_LINK_FLAGS = -pthread;-Wl,-z,relro;/usr/lib64/libwx_baseu-2.8.so;/usr/lib64/libwx_gtk2u_core-2.8.so
> -- RT_LIB = /usr/lib64/librt.so
> -- WARNING:ENABLE_ocaml is OFF so disabling Plcairo module and lablgtk2 support
> -- validate target will be available to check for syntax issues in the PLplot DocBook documentation using /usr/bin/env SP_CHARSET_FIXED=yes SP_ENCODING=xml /usr/bin/onsgmls.
> libplplot_LINK_FLAGS = /usr/lib64/libpangocairo-1.0.so;/usr/lib64/libpango-1.0.so;/usr/lib64/libgobject-2.0.so;/usr/lib64/libglib-2.0.so;/usr/lib64/libcairo.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so;/usr/lib64/libpthread.so;-pthread;-Wl,-z,relro;/usr/lib64/libwx_baseu-2.8.so;/usr/lib64/libwx_gtk2u_core-2.8.so;optimized;/usr/lib64/libQtSvg.so;debug;/usr/lib64/libQtSvg_debug.so;optimized;/usr/lib64/libQtGui.so;debug;/usr/lib64/libQtGui_debug.so;optimized;/usr/lib64/libQtCore.so;debug;/usr/lib64/libQtCore_debug.so;/usr/lib64/libm.so;/usr/lib64/libshp.so;-lcsirocsa;-lcsironn;-lqhull;-lqsastime
> -- Determine compile and link flags for extXdrawable_demo
> -- checking for module 'gtk+-x11-2.0'
> --   found gtk+-x11-2.0, version 2.24.27
> -- Determine compile and link flags for ext-cairo-test
> -- checking for module 'cairo'
> --   found cairo, version 1.14.0
> -- WARNING: The test_octave_xcairo target can be run independently but does not
>    work reliably so it is temporarily excluded from being a dependency of other
>    more general interactive test targets
> -- WARNING: The test_octave_qtwidget target can be run independently but does not
>    work reliably so it is temporarily excluded from being a dependency of other
>    more general interactive test targets
> -- WARNING: The test_c_wxwidgets target can be run independently on 
>    the Unix platform, but it generates "forced mousing" screen
>    refreshes for the wxwidgets-3.0.0 case so it is temporarily
>    excluded from being a dependency of other more general interactive
>    test targets
> -- WARNING: The test_octave_wxwidgets target can be run independently but does not
>    work reliably so it is temporarily excluded from being a dependency of other
>    more general interactive test targets
> -- WARNING: The test_octave_xwin target can be run independently but does not
>    work reliably so it is temporarily excluded from being a dependency of other
>    more general interactive test targets
> -- WARNING: The test_wxPLplotDemo target can be run independently on 
>    the Unix platform, but it generates "forced mousing" screen
>    refreshes for the wxwidgets-3.0.0 case so it is temporarily
>    excluded from being a dependency of other more general interactive
>    test targets
> -- TEST_ENVIRONMENT = EXAMPLES_DIR=/home/transient/systems/PLPLOT/plplot.git/examples SRC_EXAMPLES_DIR=/home/transient/systems/PLPLOT/plplot.git/examples OUTPUT_DIR=/home/transient/systems/PLPLOT/plplot.git/ctest_examples_output_dir VC_CTEST_DIRECTORY=
> 
> Summary of CMake build system results for PLplot
> 
> Install location variables which can be set by the user:
> CMAKE_INSTALL_PREFIX:      /usr/local
> CMAKE_INSTALL_EXEC_PREFIX  /usr/local
> CMAKE_INSTALL_BINDIR 	   /usr/local/bin
> CMAKE_INSTALL_DATADIR 	   /usr/local/share
> CMAKE_INSTALL_LIBDIR 	   /usr/local/lib
> CMAKE_INSTALL_INCLUDEDIR   /usr/local/include
> CMAKE_INSTALL_INFODIR 	   /usr/local/share/info
> CMAKE_INSTALL_MANDIR 	   /usr/local/share/man
> 
> Derived install location variables:
> DATA_DIR	/usr/local/share/plplot5.10.0
> LIB_DIR		/usr/local/lib
> INCLUDE_DIR	/usr/local/include/plplot
> BIN_DIR		/usr/local/bin
> TCL_DIR		/usr/local/share/plplot5.10.0/tcl
> ADA_INCLUDE_DIR	/usr/local/share/ada/adainclude/plplotada
> ADA_LIB_DIR	/usr/local/lib/ada/adalib/plplotada
> PYTHON_INSTDIR	/usr/local/lib64/python2.7/site-packages
> DRV_DIR		/usr/local/lib/plplot5.10.0/drivers
> DOC_DIR		/usr/local/share/doc/plplot
> MAN_DIR		/usr/local/share/man
> INFO_DIR	/usr/local/share/info
> 
> Other important CMake variables:
> 
> CMAKE_SYSTEM_NAME:	Linux
> UNIX:			1
> WIN32:			
> APPLE:			
> MSVC:				(MSVC_VERSION:	)
> MINGW:			
> MSYS:			
> CYGWIN:			
> BORLAND:		
> WATCOM:		  
> 
> SWIG_FOUND:		1
> PERL_FOUND:		TRUE
> X11_FOUND:		1
> 
> CMAKE_BUILD_TYPE:	Debug
> CMAKE_C_COMPILER CMAKE_C_FLAGS:			/usr/bin/cc 
> CMAKE_CXX_COMPILER CMAKE_CXX_FLAGS:		/usr/bin/c++ 
> CMAKE_Fortran_COMPILER CMAKE_Fortran_FLAGS:	/usr/bin/gfortran 
> Target Fortran:	
> PYTHON_EXECUTABLE:				/usr/bin/python
> PYTHON_INCLUDE_PATH:				/usr/include/python2.7
> PYTHON_LIBRARIES:				/usr/lib64/libpython2.7.so
> NUMPY_INCLUDE_PATH:				/usr/lib64/python2.7/site-packages/numpy/core/include/numpy
> 
> ENABLE_DYNDRIVERS:	OFF
> DRIVERS_LIST: cairo;qt;mem;null;ps;svg;wxwidgets;xfig;xwin
> DEVICES_LIST: memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcairo;xcairo;epsqt;pdfqt;qtwidget;bmpqt;jpgqt;pngqt;ppmqt;tiffqt;extqt;memqt;svgqt;mem;null;ps;svg;wxwidgets;xfig;xwin
> 
> Library options:
> BUILD_SHARED_LIBS:	ON		PL_DOUBLE:	ON
> 
> Optional libraries:
> PL_HAVE_QHULL:		ON		WITH_CSA:	ON
> PL_HAVE_FREETYPE:			PL_HAVE_PTHREAD:	ON
> HAVE_AGG:				HAVE_SHAPELIB:	ON
> 
> Language Bindings:
> ENABLE_ada:		OFF
> ENABLE_cxx:		ON
> ENABLE_d:		OFF
> ENABLE_f95:		ON
> ENABLE_java:		OFF
> ENABLE_lua:		OFF
> ENABLE_ocaml:		OFF
> ENABLE_octave:		ON
> ENABLE_pdl:		OFF
> ENABLE_python:		ON
> ENABLE_qt:		ON
> ENABLE_pyqt4:		OFF
> ENABLE_tcl:		OFF
> ENABLE_itcl:		OFF
> ENABLE_tk:		OFF
> ENABLE_itk:		OFF
> ENABLE_wxwidgets:	ON
> 
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/transient/systems/PLPLOT/plplot.git

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Andrew R. <and...@us...>]

> The attached patch fixes the memory leak for me. Pressing the close button
> should now behave the same as pressing 'Q', i.e. it will abort the
> program and clean up correctly. It looks like this was changed at some
> stage in the past, but I don't know why. I guess this would allow a
> programme to continue, and to potentially reopen a new xwin window. If we
> want to retain this functionality it will require a bit more thinking
> about. 

Thinking some more about this, I seem to recall the change was made
because of interactive bindings. For example, if you are using octave and
pressed the close button then the call to plabort would kill your entire
octave session which is clearly not desirable. We definitely don't want to
apply my patch as is. I need to work through all the tidy up code in
xwin.c to check exactly the path that is being followed. The current code
is doing the right thing in terms of closing the window and ignoring all
further commands to the plplot stream, we just need to ensure that the
tidy function is called at the end. A clean way of doing this would be to
have multiple levels of stream_closed. 0 = open, 1 = closed, but still
need to call tidy, 2 = closed and tidy already called.

Only the xwin and cairo drivers set this flag, but it is checked in the
core plplot code. I can simply implement this change Alan, but your call
whether you want to commit it at this late stage. It should be trivial.

Andrew

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Andrew R. <and...@us...>]

On Thu, Mar 19, 2015 at 09:08:21AM +0000, Andrew Ross wrote:
> 
> > The attached patch fixes the memory leak for me. Pressing the close button
> > should now behave the same as pressing 'Q', i.e. it will abort the
> > program and clean up correctly. It looks like this was changed at some
> > stage in the past, but I don't know why. I guess this would allow a
> > programme to continue, and to potentially reopen a new xwin window. If we
> > want to retain this functionality it will require a bit more thinking
> > about. 
> 
> Thinking some more about this, I seem to recall the change was made
> because of interactive bindings. For example, if you are using octave and
> pressed the close button then the call to plabort would kill your entire
> octave session which is clearly not desirable. We definitely don't want to
> apply my patch as is. I need to work through all the tidy up code in
> xwin.c to check exactly the path that is being followed. The current code
> is doing the right thing in terms of closing the window and ignoring all
> further commands to the plplot stream, we just need to ensure that the
> tidy function is called at the end. A clean way of doing this would be to
> have multiple levels of stream_closed. 0 = open, 1 = closed, but still
> need to call tidy, 2 = closed and tidy already called.
> 
> Only the xwin and cairo drivers set this flag, but it is checked in the
> core plplot code. I can simply implement this change Alan, but your call
> whether you want to commit it at this late stage. It should be trivial.

Further thought showed the patch was even simpler. Since only the xwin and
xcairo drivers change stream_closed, and then only when the close button
is pressed, we don't need the check of if ( ! stream_closed ) around the
call to plD_tidy. This change now removes the extra valgrind leaks when
using the close button for xwin / xcairo drivers. There are still a good
number of other leaks to investigate, but I suspect these are library
related. I have tested this with and without dynamic drivers, and also
checked no adverse affects on our clear psc results. 

Alan - your call whether to apply this or not. I am pretty confident that
this will not have adverse effects, but I would like testing by others.

Andrew

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Norman G. <no...@te...>]

During my testing, I was using the close button (X) to close the window.

Just now, I reran the xwin test by hitting "return" to close the window,
and this produced a core dump!

Thanks for looking into all this stuff.  Let me know if I can
help.

Regards,
Norm




On 03/19/2015 01:56 AM, Andrew Ross wrote:
> Norman,
>
> Thanks. This confirms that you are not using dynamic drivers. This
> explains why your fix works for you and coincides with my experiments.
> Just one further confirmation - were you closing the plplot window using
> the close button (X) on the window, or by pressing return / 'Q'?
>
> Your testing is really useful here since there are lots of different build
> options / paths through the code, even for simple examples. We have a
> pretty comprehensive set of tests, but it is hard for us to cover
> everything. For example, when running the interactive tests I always use
> return to move on to the next page so I'd not spotted this bug before.
> You've definitely highlighted one xwin driver bug - I just need to work
> out the best way to fix it. I just want to be sure there is nothing else
> lurking behind it.
>
> Thanks
>
> Andrew
>
> On Wed, Mar 18, 2015 at 09:20:29PM -0700, Norman Goldstein wrote:
>> Sorry, I just got back in ...
>> OK, I certainly bow to your more extensive insight to the plplot big
>> picture.
>> For the record, here is how I configured plolot:
>>
>> cmake -DENABLE_ocaml=OFF -DCMAKE_BUILD_TYPE=Debug. -DBUILD_TEST=ON  .
>>
>> Attached, is the cmake log.
>> I see that the default is    ENABLE_DYNDRIVERS:    OFF
>>
>> I disabled ocaml to avoid circular soft-linking that was breaking the build.
>>   I ran examples/c++/x00.cpp  to do my testing, for xw, psc and svg, for the
>> two cases of interactively typing in the device number, and of supplying
>> the -dev swtich on the command line.
>>
>> When I was first running on the downloaded code, I set a breakpoint
>> on plD_tidy_xw, and it was never hit.  That is what started me going
>> down the path I took.  Here are the results of "make test", that I just
>> ran on my patched branch:
>>
>> Running tests...
>> Test project /home/transient/systems/PLPLOT/plplot.git
>>        Start  1: examples_c
>>   1/18 Test  #1: examples_c .......................   Passed 14.57 sec
>>        Start  2: examples_cxx
>>   2/18 Test  #2: examples_cxx .....................   Passed 14.87 sec
>>        Start  3: examples_f95
>>   3/18 Test  #3: examples_f95 .....................   Passed 5.13 sec
>>        Start  4: examples_octave
>>   4/18 Test  #4: examples_octave ..................   Passed 7.60 sec
>>        Start  5: examples_python
>>   5/18 Test  #5: examples_python ..................   Passed 19.39 sec
>>        Start  6: examples_svg
>>   6/18 Test  #6: examples_svg .....................   Passed 16.68 sec
>>        Start  7: examples_pscairo
>>   7/18 Test  #7: examples_pscairo .................***Failed 0.20 sec
>>        Start  8: examples_pngcairo
>>   8/18 Test  #8: examples_pngcairo ................***Failed 0.09 sec
>>        Start  9: examples_xfig
>> *** Error in `/home/transient/systems/PLPLOT/plplot.git/examples/c/x00c':
>> double free or corruption (!prev): 0x0000000001e0d500 **
>> ...... Lots of lines------------------
>>   9/18 Test  #9: examples_xfig ....................***Failed 0.05 sec
>>        Start 10: examples_bmpqt
>> 10/18 Test #10: examples_bmpqt ...................***Failed 0.89 sec
>>        Start 11: examples_jpgqt
>> 11/18 Test #11: examples_jpgqt ...................***Failed 0.49 sec
>>        Start 12: examples_pngqt
>> 12/18 Test #12: examples_pngqt ...................***Failed 0.62 sec
>>        Start 13: examples_ppmqt
>> 13/18 Test #13: examples_ppmqt ...................***Failed 0.61 sec
>>        Start 14: examples_tiffqt
>> 14/18 Test #14: examples_tiffqt ..................***Failed 0.51 sec
>>        Start 15: examples_svgqt
>> 15/18 Test #15: examples_svgqt ...................***Failed 0.53 sec
>>        Start 16: examples_epsqt
>> 16/18 Test #16: examples_epsqt ...................***Failed 0.62 sec
>>        Start 17: examples_pdfqt
>> 17/18 Test #17: examples_pdfqt ...................***Failed 0.57 sec
>>        Start 18: examples_compare
>> 18/18 Test #18: examples_compare .................   Passed 0.27 sec
>>
>> 39% tests passed, 11 tests failed out of 18
>>
>> Total Test time (real) =  83.71 sec
>> The following tests FAILED:
>>            7 - examples_pscairo (Failed)
>>            8 - examples_pngcairo (Failed)
>>            9 - examples_xfig (Failed)
>>           10 - examples_bmpqt (Failed)
>>           11 - examples_jpgqt (Failed)
>>           12 - examples_pngqt (Failed)
>>           13 - examples_ppmqt (Failed)
>>           14 - examples_tiffqt (Failed)
>>           15 - examples_svgqt (Failed)
>>           16 - examples_epsqt (Failed)
>>           17 - examples_pdfqt (Failed)
>>
>> Cheers,
>> Norm
>>
>> On 03/18/2015 07:15 PM, Alan W. Irwin wrote:
>>> On 2015-03-18 23:39-0000 Andrew Ross wrote:
>>>
>>>> I'm a little uneasy about applying this patch so late in the release
>>>> cycle
>>>> in case there are any unforseen consequences. The current situation will
>>>> result in a memory leak when closing the window with the button, but
>>>> since
>>>> this is on exit anyway it should not be too serious.
>>> OK, Andrew. If you are uneasy about even this small a patch let's
>>> leave it for now and consider what to do about all the plend issues we
>>> currently have for a variety of device drivers after the release.
>>>
>>> Thanks for looking at this particular xwin plend issue.
>>>
>>> Alan
>>> __________________________
>>> Alan W. Irwin
>>>
>>> Astronomical research affiliation with Department of Physics and
>>> Astronomy,
>>> University of Victoria (astrowww.phys.uvic.ca).
>>>
>>> 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
>>> __________________________
>>>
>> -- Explicitly setting policy CMP0022 to OLD
>> -- Explicitly setting policy CMP0023 to OLD
>> -- CMake version = 2.8.12.2
>> -- CMAKE_SYSTEM_NAME = Linux
>> -- SH_EXECUTABLE = /usr/bin/bash
>> -- Checking whether system has ANSI C header files
>> -- ANSI C header files - found
>> -- SWIG_VERSION = 2.0.11
>> -- Looking for pkg-config - found
>> -- X11_FOUND = 1
>> -- X11_INCLUDE_DIR = /usr/include
>> -- X11_COMPILE_FLAGS = -I/usr/include
>> -- X11_LIBRARIES = /usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so
>> -- NOTICE: Found: /usr/bin/gfortran
>> -- PYTHON_VERSION = 2.7.5
>> -- Building Python binding with plsmem() support
>> -- OCTAVE = /usr/bin/octave
>> -- MKOCTFILE = /usr/bin/mkoctfile
>> -- OCTAVE_CONFIG = /usr/bin/octave-config
>> -- OCTAVE_VERSION = 3.6.4
>> -- OCTAVE_LIBRARIES = /usr/lib64/octave/3.6.4/liboctave.so
>> -- OCTINTERP_LIBRARIES = /usr/lib64/octave/3.6.4/liboctinterp.so
>> -- OCTAVE_INCLUDE_PATH = /usr/include;/usr/include/octave-3.6.4;/usr/include/octave-3.6.4/octave
>> -- PLPLOT_OCTAVE_DIR = /usr/local/share/plplot_octave
>> -- OCTAVE_M_DIR = /usr/local/share/octave/site/m
>> -- OCTAVE_OCT_DIR = /usr/local/lib/octave
>> -- WARNING: ENABLE_tcl is OFF so disabling everything else that is Tcl/Tk related
>> -- FindShapelib: Found shapelib header directory, /usr/include, and library, /usr/lib64/libshp.so.
>> -- FindQHull: Found both qhull_a.h and libqhull.a
>> -- QHULL_INCLUDE_DIRS = /usr/include
>> -- QHULL_LIBRARIES = /usr/lib64/libqhull.so
>> -- QHULL_RPATH =
>> -- checking for module 'pango'
>> --   found pango, version 1.36.1
>> -- checking for module 'pangoft2'
>> --   found pangoft2, version 1.36.1
>> -- checking for module 'pangocairo'
>> --   found pangocairo, version 1.36.1
>> -- TKLIB_COMPILE_FLAGS = -I"TK_INCLUDE_PATH-NOTFOUND"
>> -- NP_QT_COMPILE_DEFINITIONS = QT_SVG_LIB;QT_GUI_LIB;QT_CORE_LIB
>> -- QT_COMPILE_DEFINITIONS = -DQT_SVG_LIB;-DQT_GUI_LIB;-DQT_CORE_LIB
>> -- NP_QT_INCLUDE_DIRECTORIES = /usr/include;/usr/include/QtSvg;/usr/include/QtGui;/usr/include/QtCore
>> -- QT_INCLUDE_DIRECTORIES = -isystem /usr/include;-isystem /usr/include/QtSvg;-isystem /usr/include/QtGui;-isystem /usr/include/QtCore
>> -- pc_qt_COMPILE_FLAGS = -I/usr/include -I/usr/include/QtSvg -I/usr/include/QtGui -I/usr/include/QtCore
>> -- wxWidgets found
>> -- wxwidgets_COMPILE_FLAGS = -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__
>> -- wxwidgets_LINK_FLAGS = -pthread;-Wl,-z,relro;/usr/lib64/libwx_baseu-2.8.so;/usr/lib64/libwx_gtk2u_core-2.8.so
>> -- RT_LIB = /usr/lib64/librt.so
>> -- WARNING:ENABLE_ocaml is OFF so disabling Plcairo module and lablgtk2 support
>> -- validate target will be available to check for syntax issues in the PLplot DocBook documentation using /usr/bin/env SP_CHARSET_FIXED=yes SP_ENCODING=xml /usr/bin/onsgmls.
>> libplplot_LINK_FLAGS = /usr/lib64/libpangocairo-1.0.so;/usr/lib64/libpango-1.0.so;/usr/lib64/libgobject-2.0.so;/usr/lib64/libglib-2.0.so;/usr/lib64/libcairo.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so;/usr/lib64/libpthread.so;-pthread;-Wl,-z,relro;/usr/lib64/libwx_baseu-2.8.so;/usr/lib64/libwx_gtk2u_core-2.8.so;optimized;/usr/lib64/libQtSvg.so;debug;/usr/lib64/libQtSvg_debug.so;optimized;/usr/lib64/libQtGui.so;debug;/usr/lib64/libQtGui_debug.so;optimized;/usr/lib64/libQtCore.so;debug;/usr/lib64/libQtCore_debug.so;/usr/lib64/libm.so;/usr/lib64/libshp.so;-lcsirocsa;-lcsironn;-lqhull;-lqsastime
>> -- Determine compile and link flags for extXdrawable_demo
>> -- checking for module 'gtk+-x11-2.0'
>> --   found gtk+-x11-2.0, version 2.24.27
>> -- Determine compile and link flags for ext-cairo-test
>> -- checking for module 'cairo'
>> --   found cairo, version 1.14.0
>> -- WARNING: The test_octave_xcairo target can be run independently but does not
>>     work reliably so it is temporarily excluded from being a dependency of other
>>     more general interactive test targets
>> -- WARNING: The test_octave_qtwidget target can be run independently but does not
>>     work reliably so it is temporarily excluded from being a dependency of other
>>     more general interactive test targets
>> -- WARNING: The test_c_wxwidgets target can be run independently on
>>     the Unix platform, but it generates "forced mousing" screen
>>     refreshes for the wxwidgets-3.0.0 case so it is temporarily
>>     excluded from being a dependency of other more general interactive
>>     test targets
>> -- WARNING: The test_octave_wxwidgets target can be run independently but does not
>>     work reliably so it is temporarily excluded from being a dependency of other
>>     more general interactive test targets
>> -- WARNING: The test_octave_xwin target can be run independently but does not
>>     work reliably so it is temporarily excluded from being a dependency of other
>>     more general interactive test targets
>> -- WARNING: The test_wxPLplotDemo target can be run independently on
>>     the Unix platform, but it generates "forced mousing" screen
>>     refreshes for the wxwidgets-3.0.0 case so it is temporarily
>>     excluded from being a dependency of other more general interactive
>>     test targets
>> -- TEST_ENVIRONMENT = EXAMPLES_DIR=/home/transient/systems/PLPLOT/plplot.git/examples SRC_EXAMPLES_DIR=/home/transient/systems/PLPLOT/plplot.git/examples OUTPUT_DIR=/home/transient/systems/PLPLOT/plplot.git/ctest_examples_output_dir VC_CTEST_DIRECTORY=
>>
>> Summary of CMake build system results for PLplot
>>
>> Install location variables which can be set by the user:
>> CMAKE_INSTALL_PREFIX:      /usr/local
>> CMAKE_INSTALL_EXEC_PREFIX  /usr/local
>> CMAKE_INSTALL_BINDIR 	   /usr/local/bin
>> CMAKE_INSTALL_DATADIR 	   /usr/local/share
>> CMAKE_INSTALL_LIBDIR 	   /usr/local/lib
>> CMAKE_INSTALL_INCLUDEDIR   /usr/local/include
>> CMAKE_INSTALL_INFODIR 	   /usr/local/share/info
>> CMAKE_INSTALL_MANDIR 	   /usr/local/share/man
>>
>> Derived install location variables:
>> DATA_DIR	/usr/local/share/plplot5.10.0
>> LIB_DIR		/usr/local/lib
>> INCLUDE_DIR	/usr/local/include/plplot
>> BIN_DIR		/usr/local/bin
>> TCL_DIR		/usr/local/share/plplot5.10.0/tcl
>> ADA_INCLUDE_DIR	/usr/local/share/ada/adainclude/plplotada
>> ADA_LIB_DIR	/usr/local/lib/ada/adalib/plplotada
>> PYTHON_INSTDIR	/usr/local/lib64/python2.7/site-packages
>> DRV_DIR		/usr/local/lib/plplot5.10.0/drivers
>> DOC_DIR		/usr/local/share/doc/plplot
>> MAN_DIR		/usr/local/share/man
>> INFO_DIR	/usr/local/share/info
>>
>> Other important CMake variables:
>>
>> CMAKE_SYSTEM_NAME:	Linux
>> UNIX:			1
>> WIN32:			
>> APPLE:			
>> MSVC:				(MSVC_VERSION:	)
>> MINGW:			
>> MSYS:			
>> CYGWIN:			
>> BORLAND:		
>> WATCOM:		
>>
>> SWIG_FOUND:		1
>> PERL_FOUND:		TRUE
>> X11_FOUND:		1
>>
>> CMAKE_BUILD_TYPE:	Debug
>> CMAKE_C_COMPILER CMAKE_C_FLAGS:			/usr/bin/cc
>> CMAKE_CXX_COMPILER CMAKE_CXX_FLAGS:		/usr/bin/c++
>> CMAKE_Fortran_COMPILER CMAKE_Fortran_FLAGS:	/usr/bin/gfortran
>> Target Fortran:	
>> PYTHON_EXECUTABLE:				/usr/bin/python
>> PYTHON_INCLUDE_PATH:				/usr/include/python2.7
>> PYTHON_LIBRARIES:				/usr/lib64/libpython2.7.so
>> NUMPY_INCLUDE_PATH:				/usr/lib64/python2.7/site-packages/numpy/core/include/numpy
>>
>> ENABLE_DYNDRIVERS:	OFF
>> DRIVERS_LIST: cairo;qt;mem;null;ps;svg;wxwidgets;xfig;xwin
>> DEVICES_LIST: memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcairo;xcairo;epsqt;pdfqt;qtwidget;bmpqt;jpgqt;pngqt;ppmqt;tiffqt;extqt;memqt;svgqt;mem;null;ps;svg;wxwidgets;xfig;xwin
>>
>> Library options:
>> BUILD_SHARED_LIBS:	ON		PL_DOUBLE:	ON
>>
>> Optional libraries:
>> PL_HAVE_QHULL:		ON		WITH_CSA:	ON
>> PL_HAVE_FREETYPE:			PL_HAVE_PTHREAD:	ON
>> HAVE_AGG:				HAVE_SHAPELIB:	ON
>>
>> Language Bindings:
>> ENABLE_ada:		OFF
>> ENABLE_cxx:		ON
>> ENABLE_d:		OFF
>> ENABLE_f95:		ON
>> ENABLE_java:		OFF
>> ENABLE_lua:		OFF
>> ENABLE_ocaml:		OFF
>> ENABLE_octave:		ON
>> ENABLE_pdl:		OFF
>> ENABLE_python:		ON
>> ENABLE_qt:		ON
>> ENABLE_pyqt4:		OFF
>> ENABLE_tcl:		OFF
>> ENABLE_itcl:		OFF
>> ENABLE_tk:		OFF
>> ENABLE_itk:		OFF
>> ENABLE_wxwidgets:	ON
>>
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: /home/transient/systems/PLPLOT/plplot.git
>

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Andrew R. <and...@us...>]

Great! That confirms we are looking at exactly the same bug. Thanks for
the prompt response. I think I now know how to fix it. The same issue also
seems to occur with the xcairo driver.

Andrew

On Thu, Mar 19, 2015 at 02:08:38AM -0700, Norman Goldstein wrote:
> During my testing, I was using the close button (X) to close the window.
> 
> Just now, I reran the xwin test by hitting "return" to close the window,
> and this produced a core dump!
> 
> Thanks for looking into all this stuff.  Let me know if I can
> help.
> 
> Regards,
> Norm
> 
> 
> 
> 
> On 03/19/2015 01:56 AM, Andrew Ross wrote:
> > Norman,
> >
> > Thanks. This confirms that you are not using dynamic drivers. This
> > explains why your fix works for you and coincides with my experiments.
> > Just one further confirmation - were you closing the plplot window using
> > the close button (X) on the window, or by pressing return / 'Q'?
> >
> > Your testing is really useful here since there are lots of different build
> > options / paths through the code, even for simple examples. We have a
> > pretty comprehensive set of tests, but it is hard for us to cover
> > everything. For example, when running the interactive tests I always use
> > return to move on to the next page so I'd not spotted this bug before.
> > You've definitely highlighted one xwin driver bug - I just need to work
> > out the best way to fix it. I just want to be sure there is nothing else
> > lurking behind it.
> >
> > Thanks
> >
> > Andrew
> >
> > On Wed, Mar 18, 2015 at 09:20:29PM -0700, Norman Goldstein wrote:
> >> Sorry, I just got back in ...
> >> OK, I certainly bow to your more extensive insight to the plplot big
> >> picture.
> >> For the record, here is how I configured plolot:
> >>
> >> cmake -DENABLE_ocaml=OFF -DCMAKE_BUILD_TYPE=Debug. -DBUILD_TEST=ON  .
> >>
> >> Attached, is the cmake log.
> >> I see that the default is    ENABLE_DYNDRIVERS:    OFF
> >>
> >> I disabled ocaml to avoid circular soft-linking that was breaking the build.
> >>   I ran examples/c++/x00.cpp  to do my testing, for xw, psc and svg, for the
> >> two cases of interactively typing in the device number, and of supplying
> >> the -dev swtich on the command line.
> >>
> >> When I was first running on the downloaded code, I set a breakpoint
> >> on plD_tidy_xw, and it was never hit.  That is what started me going
> >> down the path I took.  Here are the results of "make test", that I just
> >> ran on my patched branch:
> >>
> >> Running tests...
> >> Test project /home/transient/systems/PLPLOT/plplot.git
> >>        Start  1: examples_c
> >>   1/18 Test  #1: examples_c .......................   Passed 14.57 sec
> >>        Start  2: examples_cxx
> >>   2/18 Test  #2: examples_cxx .....................   Passed 14.87 sec
> >>        Start  3: examples_f95
> >>   3/18 Test  #3: examples_f95 .....................   Passed 5.13 sec
> >>        Start  4: examples_octave
> >>   4/18 Test  #4: examples_octave ..................   Passed 7.60 sec
> >>        Start  5: examples_python
> >>   5/18 Test  #5: examples_python ..................   Passed 19.39 sec
> >>        Start  6: examples_svg
> >>   6/18 Test  #6: examples_svg .....................   Passed 16.68 sec
> >>        Start  7: examples_pscairo
> >>   7/18 Test  #7: examples_pscairo .................***Failed 0.20 sec
> >>        Start  8: examples_pngcairo
> >>   8/18 Test  #8: examples_pngcairo ................***Failed 0.09 sec
> >>        Start  9: examples_xfig
> >> *** Error in `/home/transient/systems/PLPLOT/plplot.git/examples/c/x00c':
> >> double free or corruption (!prev): 0x0000000001e0d500 **
> >> ...... Lots of lines------------------
> >>   9/18 Test  #9: examples_xfig ....................***Failed 0.05 sec
> >>        Start 10: examples_bmpqt
> >> 10/18 Test #10: examples_bmpqt ...................***Failed 0.89 sec
> >>        Start 11: examples_jpgqt
> >> 11/18 Test #11: examples_jpgqt ...................***Failed 0.49 sec
> >>        Start 12: examples_pngqt
> >> 12/18 Test #12: examples_pngqt ...................***Failed 0.62 sec
> >>        Start 13: examples_ppmqt
> >> 13/18 Test #13: examples_ppmqt ...................***Failed 0.61 sec
> >>        Start 14: examples_tiffqt
> >> 14/18 Test #14: examples_tiffqt ..................***Failed 0.51 sec
> >>        Start 15: examples_svgqt
> >> 15/18 Test #15: examples_svgqt ...................***Failed 0.53 sec
> >>        Start 16: examples_epsqt
> >> 16/18 Test #16: examples_epsqt ...................***Failed 0.62 sec
> >>        Start 17: examples_pdfqt
> >> 17/18 Test #17: examples_pdfqt ...................***Failed 0.57 sec
> >>        Start 18: examples_compare
> >> 18/18 Test #18: examples_compare .................   Passed 0.27 sec
> >>
> >> 39% tests passed, 11 tests failed out of 18
> >>
> >> Total Test time (real) =  83.71 sec
> >> The following tests FAILED:
> >>            7 - examples_pscairo (Failed)
> >>            8 - examples_pngcairo (Failed)
> >>            9 - examples_xfig (Failed)
> >>           10 - examples_bmpqt (Failed)
> >>           11 - examples_jpgqt (Failed)
> >>           12 - examples_pngqt (Failed)
> >>           13 - examples_ppmqt (Failed)
> >>           14 - examples_tiffqt (Failed)
> >>           15 - examples_svgqt (Failed)
> >>           16 - examples_epsqt (Failed)
> >>           17 - examples_pdfqt (Failed)
> >>
> >> Cheers,
> >> Norm
> >>
> >> On 03/18/2015 07:15 PM, Alan W. Irwin wrote:
> >>> On 2015-03-18 23:39-0000 Andrew Ross wrote:
> >>>
> >>>> I'm a little uneasy about applying this patch so late in the release
> >>>> cycle
> >>>> in case there are any unforseen consequences. The current situation will
> >>>> result in a memory leak when closing the window with the button, but
> >>>> since
> >>>> this is on exit anyway it should not be too serious.
> >>> OK, Andrew. If you are uneasy about even this small a patch let's
> >>> leave it for now and consider what to do about all the plend issues we
> >>> currently have for a variety of device drivers after the release.
> >>>
> >>> Thanks for looking at this particular xwin plend issue.
> >>>
> >>> Alan
> >>> __________________________
> >>> Alan W. Irwin
> >>>
> >>> Astronomical research affiliation with Department of Physics and
> >>> Astronomy,
> >>> University of Victoria (astrowww.phys.uvic.ca).
> >>>
> >>> 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
> >>> __________________________
> >>>
> >> -- Explicitly setting policy CMP0022 to OLD
> >> -- Explicitly setting policy CMP0023 to OLD
> >> -- CMake version = 2.8.12.2
> >> -- CMAKE_SYSTEM_NAME = Linux
> >> -- SH_EXECUTABLE = /usr/bin/bash
> >> -- Checking whether system has ANSI C header files
> >> -- ANSI C header files - found
> >> -- SWIG_VERSION = 2.0.11
> >> -- Looking for pkg-config - found
> >> -- X11_FOUND = 1
> >> -- X11_INCLUDE_DIR = /usr/include
> >> -- X11_COMPILE_FLAGS = -I/usr/include
> >> -- X11_LIBRARIES = /usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so
> >> -- NOTICE: Found: /usr/bin/gfortran
> >> -- PYTHON_VERSION = 2.7.5
> >> -- Building Python binding with plsmem() support
> >> -- OCTAVE = /usr/bin/octave
> >> -- MKOCTFILE = /usr/bin/mkoctfile
> >> -- OCTAVE_CONFIG = /usr/bin/octave-config
> >> -- OCTAVE_VERSION = 3.6.4
> >> -- OCTAVE_LIBRARIES = /usr/lib64/octave/3.6.4/liboctave.so
> >> -- OCTINTERP_LIBRARIES = /usr/lib64/octave/3.6.4/liboctinterp.so
> >> -- OCTAVE_INCLUDE_PATH = /usr/include;/usr/include/octave-3.6.4;/usr/include/octave-3.6.4/octave
> >> -- PLPLOT_OCTAVE_DIR = /usr/local/share/plplot_octave
> >> -- OCTAVE_M_DIR = /usr/local/share/octave/site/m
> >> -- OCTAVE_OCT_DIR = /usr/local/lib/octave
> >> -- WARNING: ENABLE_tcl is OFF so disabling everything else that is Tcl/Tk related
> >> -- FindShapelib: Found shapelib header directory, /usr/include, and library, /usr/lib64/libshp.so.
> >> -- FindQHull: Found both qhull_a.h and libqhull.a
> >> -- QHULL_INCLUDE_DIRS = /usr/include
> >> -- QHULL_LIBRARIES = /usr/lib64/libqhull.so
> >> -- QHULL_RPATH =
> >> -- checking for module 'pango'
> >> --   found pango, version 1.36.1
> >> -- checking for module 'pangoft2'
> >> --   found pangoft2, version 1.36.1
> >> -- checking for module 'pangocairo'
> >> --   found pangocairo, version 1.36.1
> >> -- TKLIB_COMPILE_FLAGS = -I"TK_INCLUDE_PATH-NOTFOUND"
> >> -- NP_QT_COMPILE_DEFINITIONS = QT_SVG_LIB;QT_GUI_LIB;QT_CORE_LIB
> >> -- QT_COMPILE_DEFINITIONS = -DQT_SVG_LIB;-DQT_GUI_LIB;-DQT_CORE_LIB
> >> -- NP_QT_INCLUDE_DIRECTORIES = /usr/include;/usr/include/QtSvg;/usr/include/QtGui;/usr/include/QtCore
> >> -- QT_INCLUDE_DIRECTORIES = -isystem /usr/include;-isystem /usr/include/QtSvg;-isystem /usr/include/QtGui;-isystem /usr/include/QtCore
> >> -- pc_qt_COMPILE_FLAGS = -I/usr/include -I/usr/include/QtSvg -I/usr/include/QtGui -I/usr/include/QtCore
> >> -- wxWidgets found
> >> -- wxwidgets_COMPILE_FLAGS = -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__
> >> -- wxwidgets_LINK_FLAGS = -pthread;-Wl,-z,relro;/usr/lib64/libwx_baseu-2.8.so;/usr/lib64/libwx_gtk2u_core-2.8.so
> >> -- RT_LIB = /usr/lib64/librt.so
> >> -- WARNING:ENABLE_ocaml is OFF so disabling Plcairo module and lablgtk2 support
> >> -- validate target will be available to check for syntax issues in the PLplot DocBook documentation using /usr/bin/env SP_CHARSET_FIXED=yes SP_ENCODING=xml /usr/bin/onsgmls.
> >> libplplot_LINK_FLAGS = /usr/lib64/libpangocairo-1.0.so;/usr/lib64/libpango-1.0.so;/usr/lib64/libgobject-2.0.so;/usr/lib64/libglib-2.0.so;/usr/lib64/libcairo.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so;/usr/lib64/libpthread.so;-pthread;-Wl,-z,relro;/usr/lib64/libwx_baseu-2.8.so;/usr/lib64/libwx_gtk2u_core-2.8.so;optimized;/usr/lib64/libQtSvg.so;debug;/usr/lib64/libQtSvg_debug.so;optimized;/usr/lib64/libQtGui.so;debug;/usr/lib64/libQtGui_debug.so;optimized;/usr/lib64/libQtCore.so;debug;/usr/lib64/libQtCore_debug.so;/usr/lib64/libm.so;/usr/lib64/libshp.so;-lcsirocsa;-lcsironn;-lqhull;-lqsastime
> >> -- Determine compile and link flags for extXdrawable_demo
> >> -- checking for module 'gtk+-x11-2.0'
> >> --   found gtk+-x11-2.0, version 2.24.27
> >> -- Determine compile and link flags for ext-cairo-test
> >> -- checking for module 'cairo'
> >> --   found cairo, version 1.14.0
> >> -- WARNING: The test_octave_xcairo target can be run independently but does not
> >>     work reliably so it is temporarily excluded from being a dependency of other
> >>     more general interactive test targets
> >> -- WARNING: The test_octave_qtwidget target can be run independently but does not
> >>     work reliably so it is temporarily excluded from being a dependency of other
> >>     more general interactive test targets
> >> -- WARNING: The test_c_wxwidgets target can be run independently on
> >>     the Unix platform, but it generates "forced mousing" screen
> >>     refreshes for the wxwidgets-3.0.0 case so it is temporarily
> >>     excluded from being a dependency of other more general interactive
> >>     test targets
> >> -- WARNING: The test_octave_wxwidgets target can be run independently but does not
> >>     work reliably so it is temporarily excluded from being a dependency of other
> >>     more general interactive test targets
> >> -- WARNING: The test_octave_xwin target can be run independently but does not
> >>     work reliably so it is temporarily excluded from being a dependency of other
> >>     more general interactive test targets
> >> -- WARNING: The test_wxPLplotDemo target can be run independently on
> >>     the Unix platform, but it generates "forced mousing" screen
> >>     refreshes for the wxwidgets-3.0.0 case so it is temporarily
> >>     excluded from being a dependency of other more general interactive
> >>     test targets
> >> -- TEST_ENVIRONMENT = EXAMPLES_DIR=/home/transient/systems/PLPLOT/plplot.git/examples SRC_EXAMPLES_DIR=/home/transient/systems/PLPLOT/plplot.git/examples OUTPUT_DIR=/home/transient/systems/PLPLOT/plplot.git/ctest_examples_output_dir VC_CTEST_DIRECTORY=
> >>
> >> Summary of CMake build system results for PLplot
> >>
> >> Install location variables which can be set by the user:
> >> CMAKE_INSTALL_PREFIX:      /usr/local
> >> CMAKE_INSTALL_EXEC_PREFIX  /usr/local
> >> CMAKE_INSTALL_BINDIR 	   /usr/local/bin
> >> CMAKE_INSTALL_DATADIR 	   /usr/local/share
> >> CMAKE_INSTALL_LIBDIR 	   /usr/local/lib
> >> CMAKE_INSTALL_INCLUDEDIR   /usr/local/include
> >> CMAKE_INSTALL_INFODIR 	   /usr/local/share/info
> >> CMAKE_INSTALL_MANDIR 	   /usr/local/share/man
> >>
> >> Derived install location variables:
> >> DATA_DIR	/usr/local/share/plplot5.10.0
> >> LIB_DIR		/usr/local/lib
> >> INCLUDE_DIR	/usr/local/include/plplot
> >> BIN_DIR		/usr/local/bin
> >> TCL_DIR		/usr/local/share/plplot5.10.0/tcl
> >> ADA_INCLUDE_DIR	/usr/local/share/ada/adainclude/plplotada
> >> ADA_LIB_DIR	/usr/local/lib/ada/adalib/plplotada
> >> PYTHON_INSTDIR	/usr/local/lib64/python2.7/site-packages
> >> DRV_DIR		/usr/local/lib/plplot5.10.0/drivers
> >> DOC_DIR		/usr/local/share/doc/plplot
> >> MAN_DIR		/usr/local/share/man
> >> INFO_DIR	/usr/local/share/info
> >>
> >> Other important CMake variables:
> >>
> >> CMAKE_SYSTEM_NAME:	Linux
> >> UNIX:			1
> >> WIN32:			
> >> APPLE:			
> >> MSVC:				(MSVC_VERSION:	)
> >> MINGW:			
> >> MSYS:			
> >> CYGWIN:			
> >> BORLAND:		
> >> WATCOM:		
> >>
> >> SWIG_FOUND:		1
> >> PERL_FOUND:		TRUE
> >> X11_FOUND:		1
> >>
> >> CMAKE_BUILD_TYPE:	Debug
> >> CMAKE_C_COMPILER CMAKE_C_FLAGS:			/usr/bin/cc
> >> CMAKE_CXX_COMPILER CMAKE_CXX_FLAGS:		/usr/bin/c++
> >> CMAKE_Fortran_COMPILER CMAKE_Fortran_FLAGS:	/usr/bin/gfortran
> >> Target Fortran:	
> >> PYTHON_EXECUTABLE:				/usr/bin/python
> >> PYTHON_INCLUDE_PATH:				/usr/include/python2.7
> >> PYTHON_LIBRARIES:				/usr/lib64/libpython2.7.so
> >> NUMPY_INCLUDE_PATH:				/usr/lib64/python2.7/site-packages/numpy/core/include/numpy
> >>
> >> ENABLE_DYNDRIVERS:	OFF
> >> DRIVERS_LIST: cairo;qt;mem;null;ps;svg;wxwidgets;xfig;xwin
> >> DEVICES_LIST: memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcairo;xcairo;epsqt;pdfqt;qtwidget;bmpqt;jpgqt;pngqt;ppmqt;tiffqt;extqt;memqt;svgqt;mem;null;ps;svg;wxwidgets;xfig;xwin
> >>
> >> Library options:
> >> BUILD_SHARED_LIBS:	ON		PL_DOUBLE:	ON
> >>
> >> Optional libraries:
> >> PL_HAVE_QHULL:		ON		WITH_CSA:	ON
> >> PL_HAVE_FREETYPE:			PL_HAVE_PTHREAD:	ON
> >> HAVE_AGG:				HAVE_SHAPELIB:	ON
> >>
> >> Language Bindings:
> >> ENABLE_ada:		OFF
> >> ENABLE_cxx:		ON
> >> ENABLE_d:		OFF
> >> ENABLE_f95:		ON
> >> ENABLE_java:		OFF
> >> ENABLE_lua:		OFF
> >> ENABLE_ocaml:		OFF
> >> ENABLE_octave:		ON
> >> ENABLE_pdl:		OFF
> >> ENABLE_python:		ON
> >> ENABLE_qt:		ON
> >> ENABLE_pyqt4:		OFF
> >> ENABLE_tcl:		OFF
> >> ENABLE_itcl:		OFF
> >> ENABLE_tk:		OFF
> >> ENABLE_itk:		OFF
> >> ENABLE_wxwidgets:	ON
> >>
> >> -- Configuring done
> >> -- Generating done
> >> -- Build files have been written to: /home/transient/systems/PLPLOT/plplot.git
> >
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Alan W. I. <ir...@be...>]

On 2015-03-19 09:08-0000 Andrew Ross wrote:

>
>> The attached patch fixes the memory leak for me. Pressing the close button
>> should now behave the same as pressing 'Q', i.e. it will abort the
>> program and clean up correctly. It looks like this was changed at some
>> stage in the past, but I don't know why. I guess this would allow a
>> programme to continue, and to potentially reopen a new xwin window. If we
>> want to retain this functionality it will require a bit more thinking
>> about.
>
> Thinking some more about this, I seem to recall the change was made
> because of interactive bindings. For example, if you are using octave and
> pressed the close button then the call to plabort would kill your entire
> octave session which is clearly not desirable. We definitely don't want to
> apply my patch as is. I need to work through all the tidy up code in
> xwin.c to check exactly the path that is being followed. The current code
> is doing the right thing in terms of closing the window and ignoring all
> further commands to the plplot stream, we just need to ensure that the
> tidy function is called at the end. A clean way of doing this would be to
> have multiple levels of stream_closed. 0 = open, 1 = closed, but still
> need to call tidy, 2 = closed and tidy already called.
>
> Only the xwin and cairo drivers set this flag, but it is checked in the
> core plplot code. I can simply implement this change Alan, but your call
> whether you want to commit it at this late stage. It should be trivial.

With regard to that fix you might also find -dev tk affected since
that device driver uses parts of -dev xwin if I recall correctly.

But in any case, let's stick with the idea of regression fixes only
since we are so near to release.  But by all means please implement it
on a topic branch ready to be pushed post release.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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
__________________________

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Andrew R. <and...@us...>]

On Thu, Mar 19, 2015 at 09:09:27AM -0700, Alan Irwin wrote:
> On 2015-03-19 09:08-0000 Andrew Ross wrote:
> 
> >
> >>The attached patch fixes the memory leak for me. Pressing the close button
> >>should now behave the same as pressing 'Q', i.e. it will abort the
> >>program and clean up correctly. It looks like this was changed at some
> >>stage in the past, but I don't know why. I guess this would allow a
> >>programme to continue, and to potentially reopen a new xwin window. If we
> >>want to retain this functionality it will require a bit more thinking
> >>about.
> >
> >Thinking some more about this, I seem to recall the change was made
> >because of interactive bindings. For example, if you are using octave and
> >pressed the close button then the call to plabort would kill your entire
> >octave session which is clearly not desirable. We definitely don't want to
> >apply my patch as is. I need to work through all the tidy up code in
> >xwin.c to check exactly the path that is being followed. The current code
> >is doing the right thing in terms of closing the window and ignoring all
> >further commands to the plplot stream, we just need to ensure that the
> >tidy function is called at the end. A clean way of doing this would be to
> >have multiple levels of stream_closed. 0 = open, 1 = closed, but still
> >need to call tidy, 2 = closed and tidy already called.
> >
> >Only the xwin and cairo drivers set this flag, but it is checked in the
> >core plplot code. I can simply implement this change Alan, but your call
> >whether you want to commit it at this late stage. It should be trivial.
> 
> With regard to that fix you might also find -dev tk affected since
> that device driver uses parts of -dev xwin if I recall correctly.
> 
> But in any case, let's stick with the idea of regression fixes only
> since we are so near to release.  But by all means please implement it
> on a topic branch ready to be pushed post release.

It's possible -dev tk is also affected. Anyway, I'll hold the fix until
post-release. 

Andrew

[Plplot-devel] memory leaks in wxWidgets driver?

[laurent B. <Lau...@un...>]

Hi,

I look fo memory leaks in my program using plplot 5.11. I am using vs 
2013 with Visual leak detector.
This tools finds two memory leaks in my plplot code in wxPlplotWindow.h 
at line 187(m_memory_dc) and line 195 (m_gcDc).
When I close wxPlplotwindow<> this two pointers are not deleted. May be 
I don't use good function to close wxPlplotwindow<>. Can you tell me how 
can I close it?

Thanks you for yours answers and for new version of plplot.

Re: [Plplot-devel] memory leaks in wxWidgets driver?

[Phil R. <p.d...@gm...>]

Hello Laurent
My apologies for not responding sooner. I have unfortunately not been
able to spend time on PLplot recently, but am now getting back to
things. I will look into the memory leaks you described as soon as I
can.

Phil

On 21 April 2015 at 21:42, laurent Berger <Lau...@un...> wrote:
> Hi,
>
> I look fo memory leaks in my program using plplot 5.11. I am using vs
> 2013 with Visual leak detector.
> This tools finds two memory leaks in my plplot code in wxPlplotWindow.h
> at line 187(m_memory_dc) and line 195 (m_gcDc).
> When I close wxPlplotwindow<> this two pointers are not deleted. May be
> I don't use good function to close wxPlplotwindow<>. Can you tell me how
> can I close it?
>
> Thanks you for yours answers and for new version of plplot.
>
>
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] memory leaks in wxWidgets driver?

[Phil R. <p.d...@gm...>]

 Hello Laurent
I have just fixed the memory leak bug you reported. Thanks for
reporting it. You should be able to download the fixed version from
the git repo via sourceforge.

Phil

On 21 May 2015 at 22:51, Phil Rosenberg <p.d...@gm...> wrote:
> Hello Laurent
> My apologies for not responding sooner. I have unfortunately not been
> able to spend time on PLplot recently, but am now getting back to
> things. I will look into the memory leaks you described as soon as I
> can.
>
> Phil
>
> On 21 April 2015 at 21:42, laurent Berger <Lau...@un...> wrote:
>> Hi,
>>
>> I look fo memory leaks in my program using plplot 5.11. I am using vs
>> 2013 with Visual leak detector.
>> This tools finds two memory leaks in my plplot code in wxPlplotWindow.h
>> at line 187(m_memory_dc) and line 195 (m_gcDc).
>> When I close wxPlplotwindow<> this two pointers are not deleted. May be
>> I don't use good function to close wxPlplotwindow<>. Can you tell me how
>> can I close it?
>>
>> Thanks you for yours answers and for new version of plplot.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>> Develop your own process in accordance with the BPMN 2 standard
>> Learn Process modeling best practices with Bonita BPM through live exercises
>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel