Re: [Plplot-devel] Java changes to support plsurf3d()

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

On Mon, 14 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

>
> I will not make changes to python. Can someone please made the necessary
> changes?

OK, you aroused my curiosity, I wanted to encourage all the neat stuff you
have been doing, and I also needed a quick break from my research in any
case....;-)

I just completed the python changes.  The easy part was the API change usin=
g
swig.  The tough part was tracking down the remaining inconsistencies
between the C, tcl, and python examples 8.

In both the C and python examples, the second plot (ifshade =3D=3D 1 which =
uses
the new plmesh) has a blue edge that should not be there.  The tcl example =
8
does not have this problem.  Other non-visual differences between the
examples also show up for ifshade =3D=3D 5.  All other ifshade values have =
no
differences.

I suspected some memory management problem in the underlying plmesh code fo=
r
the ifshade =3D=3D 1 differences and sure enough

valgrind ./x08c -dev xwin

does show a lot of problems, e.g.,

Conditional jump or move depends on uninitialised value(s)
Use of uninitialised value of size 8

which were not there before the last time I ran valgrind on example 8.

Joao, could you follow up on this please?  There is a nice mode in valgrind
to leap right to a gdb session whenever a memory management problem occurs
which saves an awful lot of gdb session time executing all the correct part=
s
of the code until the error is reached.  The gdb hook from valgrind only
works if you use the -g compile option (which you can get with the
--with-debug option to ./configure). The -g option also allows valgrind to
put line numbers in its output.  The last time I used valgrind this way it
only took me about 10 minutes to track down the problem, but I am leaving i=
t
to you (please), because again I am out of time, and not at all familiar
with your recent code changes.

Alan