[Wien] Possible bugs from use of uninitialized variables

[Pavel Ondračka]

Peter Blaha píše v Čt 10. 10. 2013 v 12:22 +0200:
> I'm not very familiar with valgrid, but all those reports seem not 
> relevant to me.
> It seems to complain about all allocated arrays, which are not set to 
> zero globally. But this does NOT mean that one uses uninitialized 
> variables or assumes that the compiler sets them to zero.
Valgrind doesn't complain about uninitialized variables in general. Just
when they are used in such way that they can alter the flow of the
program or generally alter the externally-visible behavior. 

I'll take the problem from mixer as an example, because contrary to the
rest of the problems, here I'm 99% sure it is a real bug.

The complex array ROKMIX in mixer.F, is only partially initialized. The
real part of the complex number is initialized somewhere (don't know
exactly where, since I haven't tracked it that much), however the
imaginary part is not. You can check this by setting the imaginary part
to some specific value right after the allocation, and then set a
breakpoint or print its value at line
mixer.F:1504  if(abs(ROKMIX(J,I)).gt.1D-12)then 
and you will see, it has the same value as set before, so it wasn't
written anywhere.
And now basically if real part of ROKMIX(J,I) is lower than 1D-12 we
would randomly fail or pass the if test, depending on what stuff is
written in the corresponding uninitialized memory.

> 
> PS: I don't have a variable "WS" in dergl.f
> WS=0.0D0 in dergl.f
My mistake, this should have been RW
> 
> We can verify this also with ifort by setting -C in the flags, and in 
> fact doing so would result in an error in f7splt due to the mistake you 
> mentioned before.
> 
> So the only problem was in f7splt.f and that should be fixed as 
> previously mentioned.
Well, this is not what valgrind does. Valgrind doesn't do static code
analysis as compilers do during compilation, but it replaces calls to
malloc and similar at runtime with his own versions and tracks the used
memory at runtime. 

To be more specific, I'll try to explain on my previous example why I
think it can't be discovered by the ifort checking. 
Although ifort probably can track, that imaginary part of ROKMIX(J,I) is
uninitialized at that point, it has no way of knowing if return value of
abs(ROKMIX(J,I)) actually depends on the uninitialized value or not,
because abs function has not been linked at that point.

> 
> (PS: I was wrong with my first reply that you need ISPLIT=15 (this 
> relates to an older version). The present if statement is intentional, 
> but still, no result from f7splt will be used (except for ISPLIT=15).
Thanks, this explains it.

I'm very grateful and I appreciate it very much, that you are looking
into this, even though this is not a problem at your platform.
Thanks again.