[Wien] Possible bugs from use of uninitialized variables

Peter Blaha pblaha at theochem.tuwien.ac.at
Fri Oct 11 08:43:50 CEST 2013


It could be that IBMs xlf compiler does "speculative execution". (I seem 
to remember, that I read that long time ago), causing these "problems".

What we often do is something like

allocate (A(1000))

do i=1,N     (where N is less than 1000 !!!)
a(i)=b(i)
...

and later we use

do i=1,N
something = a(i)*...
(maybe even with some if statement like if(a(i).lt.xx) then ....

If your compiler does these arrays "speculative, i.e. without respecting 
"if" statements or even "do-loop limits", a checking program may find 
uninitialized values.

This would explain your ROKMIX" test: We check if the values are 
basically zero and assign only those array-elements, which are non-zero.
But at the same time we also reference/use only those non-zero (and thus 
assigned) array-elements).
Of course, if you set (or test) a higher element to something, this will 
never be changed, because we never would use it.

Anyway, I guess your suggestions will not hurt anything, so I'll try to 
set those arrays you mentioned to zero right after allocation.

On 10/10/2013 05:47 PM, Pavel Ondračka wrote:
> 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
>
>
> _______________________________________________
> 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
>

-- 

                                       P.Blaha
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300             FAX: +43-1-58801-165982
Email: blaha at theochem.tuwien.ac.at    WWW: 
http://info.tuwien.ac.at/theochem/
--------------------------------------------------------------------------


More information about the Wien mailing list