Re: [Plplot-devel] valgrind warning generated by this line, why?

[Joao C. <jc...@fe...>]

On Tuesday 15 October 2002 22:43, Alan W. Irwin wrote:
> I have just been checking Joao's recent change using valgrind.  The onl=
y
> *PLplot* memory management problem that it finds now is
>
> =3D=3D9658=3D=3D Use of uninitialised value of size 8
> =3D=3D9658=3D=3D    at 0x4025DECC: plP_draw3d (plot3d.c:1451)
> =3D=3D9658=3D=3D    by 0x4025DD7A: plnxtvhi_draw (plot3d.c:1400)
> =3D=3D9658=3D=3D    by 0x4025D968: plnxtvhi (plot3d.c:1244)
> =3D=3D9822=3D=3D    by 0x4025D7D9: plnxtv (plot3d.c:1174)
> =3D=3D9822=3D=3D    by 0x4025C40E: plt3zz (plot3d.c:947)
> =3D=3D9822=3D=3D    by 0x4025BAFC: c_plot3d (plot3d.c:729)
> =3D=3D9822=3D=3D    by 0x40259611: c_plmesh (plot3d.c:100)
> =3D=3D9822=3D=3D    by 0x8049046: main (x08c.c:176)
>
> Line 1451 of plot3d.c is
>
> if (c !=3D NULL && c[--j] >=3D 0. && c[j] <=3D 1.)
>
> Under gdb for some reason I cannot print out c or j for the plP_draw3d
> stack frame, but if I use "up" to get to the plnxtvhi_draw stack frame =
j is
> 37 and c has reasonable values in it up c[35].  However, c[36] is 0.
> strongly suggesting that may be the uninitialized value that is causing=
 the
> valgrind warning.
>
> Can you have a further look at this, Joao, to see why that c value is
> uninitialized?

The source of the problem is in plnxtvhi_draw() and plnxtvlo(), where=20
plP_draw3d() is called.
The problem is to "find" the correct value "j" to pass to plP_draw3d(), a=
s=20
both plnxtvhi_draw() and plnxtvlo() are complex, dealing with hidden line=
=20
removal and maintaining two closely coupled indexes.
c[] by itself is correctly initialized in  plt3zz() and contains the ampl=
itude=20
values of the (redimensioned) "z" matrix.

The original=20
   if (c !=3D NULL && c[j] >=3D 0. && c[j] <=3D 1.)
visually failed because, as you say above, sometimes c[j] contains garbag=
e, as=20
"j" goes after the end of the "c" array.
The "--j" version does not fails visually, as it uses initialized values =
of =20
the "c" array, but I think it fails because sometimes "j" is "0".
Well, I do know the origin of the problem, but not the cure.

And if you notice the "&& c[j] >=3D 0. && c[j] <=3D 1." you would underst=
and that=20
I was aware of some possible problems, else I wouldn't check for it...

Anyway, there are several ways to color each line segment that makes up t=
he=20
mesh. Currently, I use the color of the end point. But this makes two lin=
e=20
segments that make a "V" have different colors: the lower arm, "\" is col=
ored=20
with the color of the lower end point, which is different of the color of=
 the=20
upper end point of the "/" arm; this makes the "V" have two different col=
ors,=20
which is odd -- this effect can be observed in the pronounced minimums of=
 the=20
rosenbrock function.
The mean color of each arm only works if the arms are of equal length, wh=
ich=20
is not guaranteed.

Well, work in progress... is in progress..

Joao