[Wien] Possible bugs from use of uninitialized variables

[Laurence Marks]

Sorry, but I agree with Peter & I am 99.9% certain that this is not a bug
in the mixer. The way to test this is (with ifort) to use -ftrapuv ; the
arrays are not set in mixer.F but elsewhere within some complicated
subroutines. This flag forces a fault if an undefined variable is used.

---------------------------
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu 1-847-491-3996
"Research is to see what everybody else has seen, and to think what nobody
else has thought"
Albert Szent-Gyorgi
 On Oct 10, 2013 7:23 AM, "Pavel Ondračka" <pavel.ondracka at email.cz> wrote:

> 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.
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20131010/79d36ead/attachment.htm>