[Wien] Possible bugs from use of uninitialized variables

[Pavel Ondračka]

Laurence Marks píše v Čt 10. 10. 2013 v 09:40 -0500:
> 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 ;
That is not true. According to ifort docs:
-ftrapuv
The option sets any uninitialized local variables that are allocated on
the _stack_ to a value that is typically interpreted as a very large
integer or an invalid address.

However the ROKMIX is allocated on the _heap_

Just try the test I've described earlier, set the imaginary part by hand
right after allocation and check the value right before the if check
either with debugger or just write it to stdout and you will see the
value doesn't change.
>  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
> _______________________________________________
> 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