[Wien] Possible bugs from use of uninitialized variables
Peter Blaha
pblaha at theochem.tuwien.ac.at
Thu Oct 10 12:22:26 CEST 2013
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.
PS: I don't have a variable "WS" in dergl.f
WS=0.0D0 in dergl.f
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.
(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).
On 10/09/2013 01:18 PM, Pavel Ondračka wrote:
> Dear WIEN2k list,
>
> so after I found out, that ifort by default initializes all variables to
> 0, I got quite paranoid, since this could hide bugs and easily lead to
> changes in behavior with compilers that doesn't do that. So I fired up
> valgrind, to see if there are some other occurrences.
>
> This is what I found in in the main cycle programs, however I'm not a
> valgrind expert so I'm hopping someone familiar with the code might have
> a look. Basically I could just set all the uninitialized variables to 0
> manually to mimic ifort behavior, however it would be nice if someone
> familiar with the code could just check if initialization to 0 is indeed
> the intended behavior?
>
> Lapw2: Here we got a lot of:
>
> ==9250== Conditional jump or move depends on uninitialised value(s)
> ==9250== at 0x30DE027230: cexp (s_cexp.c:57)
> ==9250== by 0x471758: l2main_ (l2main_tmp_.F:817)
> ==9250== by 0x48A1AD: MAIN__ (lapw2_tmp_.F:605)
> ==9250== by 0x48AF6F: main (lapw2_tmp_.F:5)
> ==9250== Uninitialised value was created by a heap allocation
> ==9250== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
> ==9250== by 0x411215: __xa3_MOD_init_xa3 (modules_tmp_.F:496)
> ==9250== by 0x46F9C4: l2main_ (l2main_tmp_.F:642)
> ==9250== by 0x48A1AD: MAIN__ (lapw2_tmp_.F:605)
> ==9250== by 0x48AF6F: main (lapw2_tmp_.F:5)
>
> and
>
> ==9250== Conditional jump or move depends on uninitialised value(s)
> ==9250== at 0x4AFAB0: ylm_ (ylm.f:190)
> ==9250== by 0x4714EA: l2main_ (l2main_tmp_.F:812)
> ==9250== by 0x48A1AD: MAIN__ (lapw2_tmp_.F:605)
> ==9250== by 0x48AF6F: main (lapw2_tmp_.F:5)
> ==9250== Uninitialised value was created by a heap allocation
> ==9250== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
> ==9250== by 0x411215: __xa3_MOD_init_xa3 (modules_tmp_.F:496)
> ==9250== by 0x46F9C4: l2main_ (l2main_tmp_.F:642)
> ==9250== by 0x48A1AD: MAIN__ (lapw2_tmp_.F:605)
> ==9250== by 0x48AF6F: main (lapw2_tmp_.F:5)
>
> Caused by uninitialized values of kx, ky and kx, that later propagate
> all over.
> Can be fixed by adding
> kx = 0
> ky = 0
> kz = 0
> to init_xa3 subroutine
>
> Lapw0:
>
> ==9849== Use of uninitialised value of size 8
> ==9849== at 0x30DE012FC1: __ieee754_log_sse2 (e_log.c:159)
> ==9849== by 0x45CF5F: corpbe_ (pbe1.f:337)
> ==9849== by 0x45F7BE: pbe2_ (pbe2.f:141)
> ==9849== by 0x480C09: vxclm2_ (vxclm2.f:154)
> ==9849== by 0x495F34: xcpot1_ (xcpot1.f:382)
> ==9849== by 0x44A506: MAIN__ (lapw0.F:1875)
> ==9849== by 0x455122: main (lapw0.F:10)
> ==9849== Uninitialised value was created by a heap allocation
> ==9849== at 0xD39887C: malloc (vg_replace_malloc.c:270)
> ==9849== by 0x40C8DB: dergl_spline_ (dergl.f:134)
> ==9849== by 0x40BDB2: dergl_ (dergl.f:32)
> ==9849== by 0x40E42C: drho_ (drho.f:38)
> ==9849== by 0x493AF4: xcpot1_ (xcpot1.f:195)
> ==9849== by 0x44A506: MAIN__ (lapw0.F:1875)
> ==9849== by 0x455122: main (lapw0.F:10)
>
> Can be fixed by initializing
> WS=0.0D0 in dergl.f
>
>
> Mixer:
>
> ==4495== Conditional jump or move depends on uninitialised value(s)
> ==4495== at 0x41F4E3: MAIN__ (mixer.F:1504)
> ==4495== by 0x424FB5: main (mixer.F:23)
> ==4495== Uninitialised value was created by a heap allocation
> ==4495== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
> ==4495== by 0x4160CE: MAIN__ (mixer.F:851)
> ==4495== by 0x424FB5: main (mixer.F:23)
>
> uninitialized variable is ROKMIX (well at least the imaginary part)
> and we later do stuff like this:
> mixer.F:1504 if(abs(ROKMIX(J,I)).gt.1D-12)then
> can also be fixed by initializing to 0 right after allocation
> (mixer.F:853)
> ROKMIX = (0.0D0, 0.0D0)
>
> And another one in mixer:
> ==10137== Conditional jump or move depends on uninitialised value(s)
> ==10137== at 0x45386D: limitdmix8n_ (LimitDMIX8n.F:135)
> ==10137== by 0x43B2C2: qmix8_ (qmix8.F:631)
> ==10137== by 0x41D0BB: MAIN__ (mixer.F:1313)
> ==10137== by 0x42502B: main (mixer.F:23)
> ==10137== Uninitialised value was created by a stack allocation
> ==10137== at 0x433A37: qmix8_ (qmix8.F:1)
>
> Sadly here I was not able to track down the issue as the function
> prototype at line qmix8.F:1 where the uninitialised value was tracked to
> contains over 20 parameters.
>
>
> lapw1: just a small memory leak I found while running in valgrind,
> probably harmless
>
> ==11953== 240,000 bytes in 1 blocks are definitely lost in loss record
> 71 of 72
> ==11953== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
> ==11953== by 0x453256: nn_ (nn.f:42)
> ==11953== by 0x438708: inilpw_ (inilpw.f:405)
> ==11953== by 0x43AC3F: MAIN__ (lapw1_tmp_.F:42)
> ==11953== by 0x43B322: main (lapw1_tmp_.F:2)
>
> We are leaking memory in nn.f
> Can probably be fixed by calling
> deallocate( NR,nnat,dists,pnn ) at line nn.f:145 (before RETURN
> statement)
>
> Best regards
> Pavel Ondračka
>
> _______________________________________________
> 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