PLplot

On Wed, 27 Nov 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> http://plplot.sourceforge.net/nexamples/

Looks superb, Joao!

*If you have time, motivation, etc.*, here are some additional minor
suggestions:

(1) I think you should drop example 10 because it just looks like a black
box until you expand it.  (Of course leave it in the standard examples we
have now, but there is no rule we have to show all of our examples on the
web site.)

(2) I think example 20 should be rearranged so you see "Lena" first rather
than "Saturn?"  Lena gets our user's attention more quickly....;-)

(3) Can you try for w3 validation (http://validator.w3.org/)? Our current
web site cannot be validated either, but it would be nice to have this if
possible.

If you don't wish to deal with all or any of these additional suggestions
right now, that is fine.  Just go ahead and commit to CVS and update the
live site with /home/groups/p/pl/plplot/htdocs-replace.sh.  nexamples just
looks tremendously better than our current examples so I am anxious to see
nexamples replace examples.

Alan

email: irwin@...
phone: 250-727-2902=09FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Hi Joachim,

Joachim Wuttke wrote:
> 
> On running the minimal application
> 
> main (..) {
>     plottest();
> }
> 
> void plottest () {
>     plsdev("win3");
>     plinit();
>     plend();
> }
> 
> under Visual C++ 6.0, the debugger detects memory leaks.
> The message looks like:
> 
> Detected memory leaks!
> Dumping objects ->
> {50} normal block at 0x002F2908, 48 bytes long.
>  Data: < hC  hC     *   > B0 68 43 00 A8 68 43 00 FF FF FF FF 2A 00 00 00
> {49} normal block at 0x002F2890, 48 bytes long.
>  Data: <`iC xiC         > 60 69 43 00 78 69 43 00 00 00 00 00 1E 00 00 00 ......

Oh dear. Which version are you using, the latest release 5.1.0 or the
latest CVS version? I have made some changes since the last release so
if you're not doing so already make a try with the latest CVS version.

I must admit that I have never tried the MSVC++ 6.0 debugger. Could you
please send me the instructions on how to make the debugger detect the
memory leak?

Regards,

Olof Svensson
ESRF

On Wednesday 27 November 2002 12:16, Olof Svensson wrote:
| Hi Joachim,
|
| Joachim Wuttke wrote:
| > On running the minimal application
| >
| > main (..) {
| >     plottest();
| > }
| >
| > void plottest () {
| >     plsdev("win3");
| >     plinit();
| >     plend();
| > }
| >
| > under Visual C++ 6.0, the debugger detects memory leaks.
| > The message looks like:
| >
| > Detected memory leaks!
| > Dumping objects ->
| > {50} normal block at 0x002F2908, 48 bytes long.
| >  Data: < hC  hC     *   > B0 68 43 00 A8 68 43 00 FF FF FF FF 2A 00
| > 00 00 {49} normal block at 0x002F2890, 48 bytes long.
| >  Data: <`iC xiC         > 60 69 43 00 78 69 43 00 00 00 00 00 1E 00
| > 00 00 ......

Are these the only memory leaks? They are very modest... 48 bytes...
Some leaks are expected, as for example when one duplicates a string  or=20
open a new plot/device.

In unix if we use 'valgrind' we also find leaks, but they are static,=20
i.e., they dont increasing with program complexity or looping.
As a matter of fact 'valgrind' finds more leaks in system libraries such=20
as X11 than in plplot:


[jcard@...] /src/valgrind-20020226/valgrind --leak-check=3Dyes ./x01c=20
-dev xwin
=3D=3D6103=3D=3D valgrind-20020226, a memory error detector for x86 GNU/L=
inux.
=3D=3D6103=3D=3D Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward=
=2E
=3D=3D6103=3D=3D For more details, rerun with: -v
=3D=3D6103=3D=3D=20
Plplot library version: 5.1.0
=3D=3D6103=3D=3D=20
=3D=3D6103=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 31 =
from 3)
=3D=3D6103=3D=3D malloc/free: in use at exit: 29255 bytes in 613 blocks.
=3D=3D6103=3D=3D malloc/free: 745 allocs, 132 frees, 115299 bytes allocat=
ed.
=3D=3D6103=3D=3D For counts of detected errors, rerun with: -v
=3D=3D6103=3D=3D searching for pointers to 613 not-freed blocks.

Look here                                         ^^^^^^^^^^^^^^^^^^

=3D=3D6103=3D=3D checked 5260452 bytes.
=3D=3D6103=3D=3D=20
=3D=3D6103=3D=3D definitely lost: 546 bytes in 5 blocks.

Look here                        ^^^^^^^^^^^^^^^^^^

=3D=3D6103=3D=3D possibly lost:   0 bytes in 0 blocks.
=3D=3D6103=3D=3D=20
=3D=3D6103=3D=3D 13 bytes in 1 blocks are definitely lost in loss record =
10 of=20
52
=3D=3D6103=3D=3D    at 0x400640BB: malloc (vg_clientmalloc.c:590)
=3D=3D6103=3D=3D    by 0x41ED903D: resolve_name (in=20
/usr/X11R6/lib/libX11.so.6.2)
=3D=3D6103=3D=3D    by 0x41ED9A89: _XlcLocaleDirName (in=20
/usr/X11R6/lib/libX11.so.6.2)
=3D=3D6103=3D=3D    by 0x41ED300E: _XlcDynamicLoad (in=20
/usr/X11R6/lib/libX11.so.6.2)
=3D=3D6103=3D=3D=20
=3D=3D6103=3D=3D 21 bytes in 2 blocks are definitely lost in loss record =
13 of=20
52
=3D=3D6103=3D=3D    at 0x400640BB: malloc (vg_clientmalloc.c:590)
=3D=3D6103=3D=3D    by 0x402BDE31: plstrdup (in=20
/home/jcard/plplot-head/tmp/libplplotd.so.5.1.0)
=3D=3D6103=3D=3D    by 0x402B96D8: plInitDispatchTable (in=20
/home/jcard/plplot-head/tmp/libplplotd.so.5.1.0)
=3D=3D6103=3D=3D    by 0x402B894B: pllib_init (in=20
/home/jcard/plplot-head/tmp/libplplotd.so.5.1.0)
=3D=3D6103=3D=3D=20
=3D=3D6103=3D=3D 112 bytes in 1 blocks are definitely lost in loss record=
 25 of=20
52
=3D=3D6103=3D=3D    at 0x400640BB: malloc (vg_clientmalloc.c:590)
=3D=3D6103=3D=3D    by 0x41E82CFA: XCreateGC (in /usr/X11R6/lib/libX11.so=
=2E6.2)
=3D=3D6103=3D=3D    by 0x41E0BC60: Init (in=20
/home/jcard/plplot-head/tmp/drivers/xwind_drv.so)
=3D=3D6103=3D=3D    by 0x41E0ABBD: plD_init_xw (in=20
/home/jcard/plplot-head/tmp/drivers/xwind_drv.so)
=3D=3D6103=3D=3D=20
=3D=3D6103=3D=3D 400 bytes in 1 blocks are definitely lost in loss record=
 40 of=20
52
=3D=3D6103=3D=3D    at 0x400640BB: malloc (vg_clientmalloc.c:590)
=3D=3D6103=3D=3D    by 0x41E9BC7B: XGetVisualInfo (in=20
/usr/X11R6/lib/libX11.so.6.2)
=3D=3D6103=3D=3D    by 0x41E0E4F4: AreWeGrayscale (in=20
/home/jcard/plplot-head/tmp/drivers/xwind_drv.so)
=3D=3D6103=3D=3D    by 0x41E0BB5B: OpenXwin (in=20
/home/jcard/plplot-head/tmp/drivers/xwind_drv.so)
[jcard@...


|
| Oh dear. Which version are you using, the latest release 5.1.0 or the
| latest CVS version? I have made some changes since the last release
| so if you're not doing so already make a try with the latest CVS
| version.
|
| I must admit that I have never tried the MSVC++ 6.0 debugger. Could
| you please send me the instructions on how to make the debugger
| detect the memory leak?
|
| Regards,
|
| Olof Svensson
| ESRF
|
|
| -------------------------------------------------------
| This SF.net email is sponsored by: Get the new Palm Tungsten T
| handheld. Power & Color in a compact size!
| http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
| _______________________________________________
| Plplot-devel mailing list
| Plplot-devel@...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

On Wed, 27 Nov 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> Are these the only memory leaks? They are very modest... 48 bytes...
> Some leaks are expected, as for example when one duplicates a string  or
> open a new plot/device.
>
> In unix if we use 'valgrind' we also find leaks, but they are static,
> i.e., they dont increasing with program complexity or looping.
> As a matter of fact 'valgrind' finds more leaks in system libraries such
> as X11 than in plplot:

It has become a point of pride that KDE went through all its code to get ri=
d
of memory leaks found by valgrind so I suspect that developers for XFree86
and some of the other Linux system libraries will soon follow.  It would be
a nice point of pride with us as well.

In a prior post to this list I documented every PLplot leak found by
valgrind.  See
http://sourceforge.net/mailarchive/message.php?msg_id=3D1785861.  To fix th=
ese
should be straightforward so I strongly encourage somebody with a good
understanding of plplot initialization and termination to take up this
challenge.

Once PLplot has a clean bill of health from valgrind, it will be most
interesting to see whether the windows debugger still finds memory leaks
(and whether they are associated with PLplot or the windows libraries that
it uses).

Alan

email: irwin@...
phone: 250-727-2902=09FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Joachim Wuttke wrote:
> 
> I built the plplot/tmp stuff with configuration option --with-double,
> then I went to sys/win32/msdev and built plplib/plplot.lib without any further explicit configuring.

The sys/win32/msdev port of plplot doesn't make use of configure, just
nmake as mentioned in the INSTALL.txt file. How did you manage to run
configure? Did you use cygwin? 
 
> As far as I see, the resulting object expects me to pass data as floats.
> Is that correct, and how could I possibly build a double precision plplotd.lib ?

As I didn't make use of configure I hardwired the compilation options
into the makefile in plplot/sys/win32/msdev. If you'd like to use double
instead of float make the following change and run nmake again:

Makefile with float (i.e. current one):

> #
> # Create plconfig.h file
> #
>   @echo ``
>   @echo `Creating $(PLTMP)\plplot\plconfig.h`
>   @echo <<$(PLTMP)\plplot\plconfig.h
> #ifndef __PLCONFIG_H__
> #define __PLCONFIG_H__
> #define LIB_DIR "$(PLLIB:\=\\)"
> #define BIN_DIR "$(PLBIN:\=\\)"
> #define PLPLOT_VERSION "5.1.0"
> #endif
> <<keep

Makefile with double:

> #
> # Create plconfig.h file
> #
>   @echo ``
>   @echo `Creating $(PLTMP)\plplot\plconfig.h`
>   @echo <<$(PLTMP)\plplot\plconfig.h
> #ifndef __PLCONFIG_H__
> #define __PLCONFIG_H__
> #define LIB_DIR "$(PLLIB:\=\\)"
> #define BIN_DIR "$(PLBIN:\=\\)"
> #define PLPLOT_VERSION "5.1.0"
> #define PL_DOUBLE 1
> #endif
> <<keep

I hope this helps,

Olof