PLplot

Dear Florian,

Perhaps you can give us more details of what you are doing? These functions 
are basic plplot functions and are well tested. Our first 3 examples cover 
all of these cases. Using valgrind under Linux and the psc driver all 
three of these examples produce completely clean results with the current 
svn version. It seems unlikely therefore that is is an intrinsic problem 
with plplot. Do you see the problems with these 3 examples?

To pin down your problem will require more information. In particular
- a clearer description of your code (if you can condense it to a very 
  simple example which exhibits the problem that is immensely helpful)
- what version of plplot you are using
- what platform (e.g. Windows MinGW,  Linux etc)
- what drivers you are using (some drivers with external library 
  dependencies exhibit memory leaks related to bugs in the library and 
  not to plplot itself)
- how you are testing for memory leaks (on Linux valgrind is a very useful 
  tool)

Regards

Andrew

On Thu, Nov 22, 2012 at 04:43:37PM +0100, florian.kehrle@... wrote:
> Hi,
> 
> I get memory leaks for the following plplot functions and I couldn't  
> find anything related to that topic.
> 
> plptex using any 'just' value != 0.0
> plbox using option 'n'
> plmtex
> pllab
> 
> It's a bigger program so the memory leaks in gigabyte size, which is not nice.
> Any suggestions, what I'm doing wrong or is it a plplot problem?
> 
> Thanks,
> Flo.
> 
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Plplot-general mailing list
> Plplot-general@...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>

Dear Andrew,

thanks for the quick reply. My plplot version is 5.9.9 and I use the  
current cairo driver on Ubuntu12.10.
I tried plplot example02 with a full valgrind memory leak check. Same  
problem for the plptex function. With "just"=0.0 no problem, with  
"just" any different number the following valgrind output (as an  
example). Line 152 is the plptex function:
  plptex( 0.5, 0.5, 1.0, 0.0, 0.5, text );

==7448== 500,000 bytes in 100 blocks are definitely lost in loss  
record 795 of 795
==7448==    at 0x4C2B3F8: malloc (in  
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7448==    by 0x7195E7B: ??? (in /usr/lib/plplot5.9.9/driversd/cairo.so)
==7448==    by 0x4E4A5C8: plP_esc (in /usr/lib/libplplotd.so.11.0.0)
==7448==    by 0x4E4D53B: ??? (in /usr/lib/libplplotd.so.11.0.0)
==7448==    by 0x4E6A989: c_plmtex (in /usr/lib/libplplotd.so.11.0.0)
==7448==    by 0x4E6AF84: ??? (in /usr/lib/libplplotd.so.11.0.0)
==7448==    by 0x4E6B2C7: c_plptex (in /usr/lib/libplplotd.so.11.0.0)
==7448==    by 0x401385: draw_windows(int, int) (plot_test.cpp:152)
==7448==    by 0x4011BA: demo2() (plot_test.cpp:115)
==7448==    by 0x400EF1: main (plot_test.cpp:30)

Cheers
Flo.

Quoting Andrew Ross <andrewross@...>:

>
> Dear Florian,
>
> Perhaps you can give us more details of what you are doing? These functions
> are basic plplot functions and are well tested. Our first 3 examples cover
> all of these cases. Using valgrind under Linux and the psc driver all
> three of these examples produce completely clean results with the current
> svn version. It seems unlikely therefore that is is an intrinsic problem
> with plplot. Do you see the problems with these 3 examples?
>
> To pin down your problem will require more information. In particular
> - a clearer description of your code (if you can condense it to a very
>   simple example which exhibits the problem that is immensely helpful)
> - what version of plplot you are using
> - what platform (e.g. Windows MinGW,  Linux etc)
> - what drivers you are using (some drivers with external library
>   dependencies exhibit memory leaks related to bugs in the library and
>   not to plplot itself)
> - how you are testing for memory leaks (on Linux valgrind is a very useful
>   tool)
>
> Regards
>
> Andrew
>
> On Thu, Nov 22, 2012 at 04:43:37PM +0100,   
> florian.kehrle@... wrote:
>> Hi,
>>
>> I get memory leaks for the following plplot functions and I couldn't
>> find anything related to that topic.
>>
>> plptex using any 'just' value != 0.0
>> plbox using option 'n'
>> plmtex
>> pllab
>>
>> It's a bigger program so the memory leaks in gigabyte size, which   
>> is not nice.
>> Any suggestions, what I'm doing wrong or is it a plplot problem?
>>
>> Thanks,
>> Flo.
>>
>>
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> _______________________________________________
>> Plplot-general mailing list
>> Plplot-general@...
>> https://lists.sourceforge.net/lists/listinfo/plplot-general
>>
>

On 2012-11-22 22:13+0100 florian.kehrle@... wrote:

> Dear Andrew,
>
> thanks for the quick reply. My plplot version is 5.9.9 and I use the
> current cairo driver on Ubuntu12.10.

@Florian:
Just to jump in here late, we actually need the exact command you used
with example 2.

@Andrew:

I get valgrind clean results (for the svn trunk version of PLplot
built on Debian wheezy) for both

valgrind examples/c/x02c -dev pngcairo -o test.png -fam

and

valgrind examples/c/x02c -dev pngcairo -o test.png

In sharp contrast to those good results

valgrind examples/c/x02c -dev pscairo -o test.ps -fam

and

valgrind examples/c/x02c -dev pscairo -o test.ps

both have dirty valgrind results.  Pending more precise information
from Florian, my results may confirm what Florian has found (if in
fact he used -dev pscairo) or it may be an additional valgrind issue
that is unrelated to what he found.

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
__________________________

On Thu, Nov 22, 2012 at 09:10:08PM -0800, Alan Irwin wrote:
> On 2012-11-22 22:13+0100 florian.kehrle@... wrote:
> 
> > Dear Andrew,
> >
> > thanks for the quick reply. My plplot version is 5.9.9 and I use the
> > current cairo driver on Ubuntu12.10.
> 
> @Florian:
> Just to jump in here late, we actually need the exact command you used
> with example 2.
> 
> @Andrew:
> 
> I get valgrind clean results (for the svn trunk version of PLplot
> built on Debian wheezy) for both
> 
> valgrind examples/c/x02c -dev pngcairo -o test.png -fam
> 
> and
> 
> valgrind examples/c/x02c -dev pngcairo -o test.png
> 
> In sharp contrast to those good results
> 
> valgrind examples/c/x02c -dev pscairo -o test.ps -fam
> 
> and
> 
> valgrind examples/c/x02c -dev pscairo -o test.ps
> 
> both have dirty valgrind results.  Pending more precise information
> from Florian, my results may confirm what Florian has found (if in
> fact he used -dev pscairo) or it may be an additional valgrind issue
> that is unrelated to what he found.

Alan,

This is odd, because there definitely seems to be a bug in the plplot
code path for plotting text. I've just fixed it now. This gave
problems for both pngcairo and pscairo for me. This involved leaking
quite large amounts of memory, so I suspect this was Florian's
problem. On my Ubuntu system I still see a number of small leaks which
appear to be cairo / freetype related rather than plplot related.

@Alan Can you check my fix on Debian wheezy?

@Florian You might want to check the latest svn version of plplot to
see if this fixes your problem.

Regards
Andrew

Hi Guys,

it worked with the libraries in the new svn version - all plplot leaks  
disappeared. Now I have just some GTK related leaks left - but that  
shouldn't bother you.

THANKS a lot for the fast and efficient help!!

Flo.

Quoting Andrew Ross <andrewross@...>:

> On Thu, Nov 22, 2012 at 09:10:08PM -0800, Alan Irwin wrote:
>> On 2012-11-22 22:13+0100 florian.kehrle@... wrote:
>>
>> > Dear Andrew,
>> >
>> > thanks for the quick reply. My plplot version is 5.9.9 and I use the
>> > current cairo driver on Ubuntu12.10.
>>
>> @Florian:
>> Just to jump in here late, we actually need the exact command you used
>> with example 2.
>>
>> @Andrew:
>>
>> I get valgrind clean results (for the svn trunk version of PLplot
>> built on Debian wheezy) for both
>>
>> valgrind examples/c/x02c -dev pngcairo -o test.png -fam
>>
>> and
>>
>> valgrind examples/c/x02c -dev pngcairo -o test.png
>>
>> In sharp contrast to those good results
>>
>> valgrind examples/c/x02c -dev pscairo -o test.ps -fam
>>
>> and
>>
>> valgrind examples/c/x02c -dev pscairo -o test.ps
>>
>> both have dirty valgrind results.  Pending more precise information
>> from Florian, my results may confirm what Florian has found (if in
>> fact he used -dev pscairo) or it may be an additional valgrind issue
>> that is unrelated to what he found.
>
> Alan,
>
> This is odd, because there definitely seems to be a bug in the plplot
> code path for plotting text. I've just fixed it now. This gave
> problems for both pngcairo and pscairo for me. This involved leaking
> quite large amounts of memory, so I suspect this was Florian's
> problem. On my Ubuntu system I still see a number of small leaks which
> appear to be cairo / freetype related rather than plplot related.
>
> @Alan Can you check my fix on Debian wheezy?
>
> @Florian You might want to check the latest svn version of plplot to
> see if this fixes your problem.
>
> Regards
> Andrew
>
>

Excellent. I'm glad we managed to track it down so quickly. Thanks for
your bug report.

Andrew

On Fri, Nov 23, 2012 at 03:49:34PM +0100, florian.kehrle@... wrote:
> Hi Guys,
> 
> it worked with the libraries in the new svn version - all plplot leaks  
> disappeared. Now I have just some GTK related leaks left - but that  
> shouldn't bother you.
> 
> THANKS a lot for the fast and efficient help!!
> 
> Flo.
> 
> Quoting Andrew Ross <andrewross@...>:
> 
> > On Thu, Nov 22, 2012 at 09:10:08PM -0800, Alan Irwin wrote:
> >> On 2012-11-22 22:13+0100 florian.kehrle@... wrote:
> >>
> >> > Dear Andrew,
> >> >
> >> > thanks for the quick reply. My plplot version is 5.9.9 and I use the
> >> > current cairo driver on Ubuntu12.10.
> >>
> >> @Florian:
> >> Just to jump in here late, we actually need the exact command you used
> >> with example 2.
> >>
> >> @Andrew:
> >>
> >> I get valgrind clean results (for the svn trunk version of PLplot
> >> built on Debian wheezy) for both
> >>
> >> valgrind examples/c/x02c -dev pngcairo -o test.png -fam
> >>
> >> and
> >>
> >> valgrind examples/c/x02c -dev pngcairo -o test.png
> >>
> >> In sharp contrast to those good results
> >>
> >> valgrind examples/c/x02c -dev pscairo -o test.ps -fam
> >>
> >> and
> >>
> >> valgrind examples/c/x02c -dev pscairo -o test.ps
> >>
> >> both have dirty valgrind results.  Pending more precise information
> >> from Florian, my results may confirm what Florian has found (if in
> >> fact he used -dev pscairo) or it may be an additional valgrind issue
> >> that is unrelated to what he found.
> >
> > Alan,
> >
> > This is odd, because there definitely seems to be a bug in the plplot
> > code path for plotting text. I've just fixed it now. This gave
> > problems for both pngcairo and pscairo for me. This involved leaking
> > quite large amounts of memory, so I suspect this was Florian's
> > problem. On my Ubuntu system I still see a number of small leaks which
> > appear to be cairo / freetype related rather than plplot related.
> >
> > @Alan Can you check my fix on Debian wheezy?
> >
> > @Florian You might want to check the latest svn version of plplot to
> > see if this fixes your problem.
> >
> > Regards
> > Andrew
> >
> >
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Plplot-general mailing list
> Plplot-general@...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>

On 2012-11-23 12:13-0000 Andrew Ross wrote:

> Alan,
>
> This is odd, because there definitely seems to be a bug in the plplot
> code path for plotting text. I've just fixed it now. This gave
> problems for both pngcairo and pscairo for me.

That is odd indeed that the valgrind run for me for pngcairo was fine,
but not for you.  However, I have just run the same two tests again
with your change (at revision 12279)

valgrind examples/c/x02c -dev pngcairo -o test.png -fam
valgrind examples/c/x02c -dev pngcairo -o test.png

and all continues to be well for me.  However, I still get
valgrind problems with pscairo, e.g.,

software@...> valgrind --num-callers=40 \
examples/c/x02c -dev pscairo -o test.ps
==4666== Memcheck, a memory error detector
==4666== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==4666== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright
info
==4666== Command: examples/c/x02c -dev pscairo -o test.ps
==4666== 
==4666== Invalid read of size 4
==4666==    at 0x74E2145: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74E3742: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74E3C20: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x75109C9: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74E09DD: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x7511067: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C668B: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C6ACC: cairo_surface_finish (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74A1AD3: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C668B: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C679C: cairo_surface_destroy (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x6E019A9: plD_tidy_cairo (in
/home/software/plplot_svn/HEAD/build_dir/drivers/cairo.so)
==4666==    by 0x4E4F0FE: c_plend1 (in
/home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
==4666==    by 0x4E4F162: c_plend (in
/home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
==4666==    by 0x400D8A: main (in
/home/software/plplot_svn/HEAD/build_dir/examples/c/x02c)
==4666==  Address 0xb8280b8 is 8 bytes inside a block of size 11 alloc'd
==4666==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==4666==    by 0x74E21F1: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74E3742: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74E3C20: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x75109C9: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74E09DD: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x7511067: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C668B: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C6ACC: cairo_surface_finish (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74A1AD3: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C668B: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C679C: cairo_surface_destroy (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x6E019A9: plD_tidy_cairo (in
/home/software/plplot_svn/HEAD/build_dir/drivers/cairo.so)
==4666==    by 0x4E4F0FE: c_plend1 (in
/home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
==4666==    by 0x4E4F162: c_plend (in
/home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
==4666==    by 0x400D8A: main (in
/home/software/plplot_svn/HEAD/build_dir/examples/c/x02c)
==4666== 
==4666== 
==4666== HEAP SUMMARY:
==4666==     in use at exit: 387,975 bytes in 2,703 blocks
==4666==   total heap usage: 19,606 allocs, 16,903 frees, 4,869,363
bytes allocated
==4666== 
==4666== LEAK SUMMARY:
==4666==    definitely lost: 4,440 bytes in 8 blocks
==4666==    indirectly lost: 16,160 bytes in 503 blocks
==4666==      possibly lost: 56,513 bytes in 157 blocks
==4666==    still reachable: 310,862 bytes in 2,035 blocks
==4666==         suppressed: 0 bytes in 0 blocks
==4666== Rerun with --leak-check=full to see details of leaked memory
==4666== 
==4666== For counts of detected and suppressed errors, rerun with: -v
==4666== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7)

If you cannot replicate that, then presumably the update between my
version (pango-1.30.0-1, cairo-1.12.2-2) and yours (or else an
improved valgrind suppressions file in your case) solved this problem,
and the issue is nothing for us to worry about.

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
__________________________

On Fri, Nov 23, 2012 at 09:48:58AM -0800, Alan Irwin wrote:
> On 2012-11-23 12:13-0000 Andrew Ross wrote:
> 
> > Alan,
> >
> > This is odd, because there definitely seems to be a bug in the plplot
> > code path for plotting text. I've just fixed it now. This gave
> > problems for both pngcairo and pscairo for me.
> 
> That is odd indeed that the valgrind run for me for pngcairo was fine,
> but not for you.  However, I have just run the same two tests again
> with your change (at revision 12279)
> 
> valgrind examples/c/x02c -dev pngcairo -o test.png -fam
> valgrind examples/c/x02c -dev pngcairo -o test.png
> 
> and all continues to be well for me.  However, I still get
> valgrind problems with pscairo, e.g.,
> 
> software@...> valgrind --num-callers=40 \
> examples/c/x02c -dev pscairo -o test.ps
> ==4666== Memcheck, a memory error detector
> ==4666== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==4666== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright
> info
> ==4666== Command: examples/c/x02c -dev pscairo -o test.ps
> ==4666== 
> ==4666== Invalid read of size 4
> ==4666==    at 0x74E2145: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74E3742: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74E3C20: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x75109C9: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74E09DD: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x7511067: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C668B: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C6ACC: cairo_surface_finish (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74A1AD3: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C668B: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C679C: cairo_surface_destroy (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x6E019A9: plD_tidy_cairo (in
> /home/software/plplot_svn/HEAD/build_dir/drivers/cairo.so)
> ==4666==    by 0x4E4F0FE: c_plend1 (in
> /home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
> ==4666==    by 0x4E4F162: c_plend (in
> /home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
> ==4666==    by 0x400D8A: main (in
> /home/software/plplot_svn/HEAD/build_dir/examples/c/x02c)
> ==4666==  Address 0xb8280b8 is 8 bytes inside a block of size 11 alloc'd
> ==4666==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
> ==4666==    by 0x74E21F1: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74E3742: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74E3C20: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x75109C9: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74E09DD: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x7511067: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C668B: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C6ACC: cairo_surface_finish (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74A1AD3: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C668B: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C679C: cairo_surface_destroy (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x6E019A9: plD_tidy_cairo (in
> /home/software/plplot_svn/HEAD/build_dir/drivers/cairo.so)
> ==4666==    by 0x4E4F0FE: c_plend1 (in
> /home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
> ==4666==    by 0x4E4F162: c_plend (in
> /home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
> ==4666==    by 0x400D8A: main (in
> /home/software/plplot_svn/HEAD/build_dir/examples/c/x02c)
> ==4666== 
> ==4666== 
> ==4666== HEAP SUMMARY:
> ==4666==     in use at exit: 387,975 bytes in 2,703 blocks
> ==4666==   total heap usage: 19,606 allocs, 16,903 frees, 4,869,363
> bytes allocated
> ==4666== 
> ==4666== LEAK SUMMARY:
> ==4666==    definitely lost: 4,440 bytes in 8 blocks
> ==4666==    indirectly lost: 16,160 bytes in 503 blocks
> ==4666==      possibly lost: 56,513 bytes in 157 blocks
> ==4666==    still reachable: 310,862 bytes in 2,035 blocks
> ==4666==         suppressed: 0 bytes in 0 blocks
> ==4666== Rerun with --leak-check=full to see details of leaked memory
> ==4666== 
> ==4666== For counts of detected and suppressed errors, rerun with: -v
> ==4666== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7)
> 
> If you cannot replicate that, then presumably the update between my
> version (pango-1.30.0-1, cairo-1.12.2-2) and yours (or else an
> improved valgrind suppressions file in your case) solved this problem,
> and the issue is nothing for us to worry about.

Alan,

I don't see this warning at all. Instead, for both pscairo and pngcairo 
I see invalid reads inside pango_layout_get_pixel_size called from 
text_end_cairo. The block is allocated from within the same function. 
This, along with the fact you don't see the messages makes me suspect 
that this is a cairo / pango leak. I suspect yours is also a cairo 
related problem for similar reasons. It's just our different respective
versions have different problems!

There are still a number of smaller leaks in both our cases that may be 
worth some further checks by someone with a better grasp of cairo.

Andrew

On 2012-11-17 17:55-0500 Hazen Babcock wrote:

> On 09/21/2012 03:01 PM, Alan W. Irwin wrote:
>> On 2012-09-21 08:22-0600 James Tappin wrote:
>>
>>> In principle I would think that the cairo driver should be able to do eps
>>> via the  cairo_ps_surface_set_eps<http://www.cairographics.org/manual/cairo-PostScript-Surfaces.html#cairo-ps-surface-set-eps>function.
>>
>> Thanks for pointing out that possibility which does look like it could
>> be the basis of an -eps driver option for the pscairo device.
>
> Added (c12275) As it stands now it comes at the end of the list of cairo
> device choices, while it might make more sense that it is listed next to
> the pscairo driver?

Ideally it would be either that or the idea could be implemented as a
simple driver option for pscairo since presumably most of the
current epscairo code is identical to the pscairo code.

Of course, regardless of further tweaks you may decide to do it is
great that you have implemented this possibility.

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
__________________________

On 11/17/2012 07:18 PM, Alan W. Irwin wrote:
> On 2012-11-17 17:55-0500 Hazen Babcock wrote:
>>
>> Added (c12275) As it stands now it comes at the end of the list of cairo
>> device choices, while it might make more sense that it is listed next to
>> the pscairo driver?
>
> Ideally it would be either that or the idea could be implemented as a
> simple driver option for pscairo since presumably most of the
> current epscairo code is identical to the pscairo code.
>
> Of course, regardless of further tweaks you may decide to do it is
> great that you have implemented this possibility.

I re-ordered the Cairo drivers and left it as a separate driver. It is 
of course very similar to the PS driver, but it uses family plotting 
like the PNG or SVG driver for multiple pages of plots.

-Hazen

Which driver are you using? 

It depends on the driver. If the driver supports solid fills (most do)
then the default pattern fill style ( equivalent to calling plpsty(0)
) is a solid fill. You don't need to do anything other than call
plfill. I notice this is not really documented in the man pages. I'll
get that fixed!

See e.g. example 12 to see this in action.

Andrew


On Wed, Nov 14, 2012 at 09:22:05AM -0700, James Tappin wrote:
> Is there any way to fill a 2-D polygon with a solid colour? (other than
> setting up a very dense pattern in plpat and using plfill).

> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov

> _______________________________________________
> Plplot-general mailing list
> Plplot-general@...
> https://lists.sourceforge.net/lists/listinfo/plplot-general

On 16 November 2012 02:55, Andrew Ross <andrewross@...:

>
> Which driver are you using?
>
> It depends on the driver. If the driver supports solid fills (most do)
> then the default pattern fill style ( equivalent to calling plpsty(0)
> ) is a solid fill. You don't need to do anything other than call
> plfill. I notice this is not really documented in the man pages. I'll
> get that fixed!
>
> See e.g. example 12 to see this in action.
>
> Andrew
>
> Thanks.

The key would be to  add a note that plpsty(0) is solid fill.

James

On Fri, Nov 16, 2012 at 08:02:05AM -0700, James Tappin wrote:
> On 16 November 2012 02:55, Andrew Ross <andrewross@...:
> 
> >
> > Which driver are you using?
> >
> > It depends on the driver. If the driver supports solid fills (most do)
> > then the default pattern fill style ( equivalent to calling plpsty(0)
> > ) is a solid fill. You don't need to do anything other than call
> > plfill. I notice this is not really documented in the man pages. I'll
> > get that fixed!
> >
> > See e.g. example 12 to see this in action.
> >
> > Andrew
> >
> > Thanks.
> 
> The key would be to  add a note that plpsty(0) is solid fill.

I've checked the changes into svn. Thanks for bringing this up.

Andrew

On 16 November 2012 08:55, Yuan, Fang <fang.yuan@...> wrote:

>   I installed plplot11 in Ubuntu 11.10.
>
> I use plline() in the subroutine xy_plt1 of  "gsa.h" file, they keep
> warned me as follows:
>
> ./gsa.h: In function ‘xy_plt1’:
> ./gsa.h:167:4: warning: passing argument 2 of ‘c_plline’ from incompatible
> pointer type [enabled by default]
> /usr/include/plplot/plplot.h:1260:1: note: expected ‘const PLFLT *’ but
> argument is of type ‘float *’
> ./gsa.h:167:4: warning: passing argument 3 of ‘c_plline’ from incompatible
> pointer type [enabled by default]
> /usr/include/plplot/plplot.h:1260:1: note: expected ‘const PLFLT *’ but
> argument is of type ‘float *’
>
>
>  void    xy_plt1 ( int nn, float xn[], float yn[])
>
> The commends I used in plline is:
> plline( nn, xn, yn);
>
> The plline only draw one string line.
>
> Does anyone know how to fix it?
>

PLFLT is in most installations set to be a double rather than a float. By
using the PLFLT macro, you will be compatible with either possibility If it
is not feasible to change the calling code, then you should convert before
plotting the data.