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

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

On Wed, 16 Oct 2002, Joao Cardoso wrote:

> On Tuesday 15 October 2002 22:43, Alan W. Irwin wrote:
> > I have just been checking Joao's recent change using valgrind.  The only
> > *PLplot* memory management problem that it finds now is
> >
> > ==9658== Use of uninitialised value of size 8
> > ==9658==    at 0x4025DECC: plP_draw3d (plot3d.c:1451)
> > ==9658==    by 0x4025DD7A: plnxtvhi_draw (plot3d.c:1400)
> > ==9658==    by 0x4025D968: plnxtvhi (plot3d.c:1244)
> > ==9822==    by 0x4025D7D9: plnxtv (plot3d.c:1174)
> > ==9822==    by 0x4025C40E: plt3zz (plot3d.c:947)
> > ==9822==    by 0x4025BAFC: c_plot3d (plot3d.c:729)
> > ==9822==    by 0x40259611: c_plmesh (plot3d.c:100)
> > ==9822==    by 0x8049046: main (x08c.c:176)
> >
> > Line 1451 of plot3d.c is
> >
> > if (c != NULL && c[--j] >= 0. && c[j] <= 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
> plP_draw3d() is called.
> The problem is to "find" the correct value "j" to pass to plP_draw3d(), as
> both plnxtvhi_draw() and plnxtvlo() are complex, dealing with hidden line
> removal and maintaining two closely coupled indexes.
> c[] by itself is correctly initialized in  plt3zz() and contains the amplitude
> values of the (redimensioned) "z" matrix.
>
> The original
>    if (c != NULL && c[j] >= 0. && c[j] <= 1.)
> visually failed because, as you say above, sometimes c[j] contains garbage, as
> "j" goes after the end of the "c" array.
> The "--j" version does not fails visually, as it uses initialized values of
> 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] >= 0. && c[j] <= 1." you would understand that
> I was aware of some possible problems, else I wouldn't check for it...

Actually, I had no clue this was a line you had been working with.  (I know,
I could have looked at the diffs of your version compared to previous, but
instead I was just following what valgrind told me.)

There is one misunderstanding that should be cleared up here.  valgrind
warns of an uninitialized variable for your current version when j = 27.
Your c[--j] then looks at c[26] as does the c[j] after it.  But that is
still uninitialized (according to valgrind and also gdb shows its value is
0.) As I said in my post the last initialized value is c[25].  The obvious
solution is to constrain j so that the references to c always stay within
the initialized bounds.  Can that be done?

Also, referring to your next post about tcl precision I agree it is possible
that could be the cause of the difference with C and python.  But that
cannot explain the python -- C difference (both our double precision).  So
my working hypothesis remains the same.  Once C and python agree, then it
will be most interesting to see whether tcl falls into line or whether its
12 digits or precision will make a difference.  Typically, it does not
make a difference on other examples, but we will see once the uninitialized
variable is taken care of.

Alan