[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