Hi all
I am trying to compile (on my Mac) an R package (tweedie) which includes Fortran 77 code. I?m not much of a programmer, but can still manage to write and update F77 code. I?m new to valgrind.
In checking my package (which passes the build-and-check with no errors), I use valgrind like this:
R -d "valgrind --tool=memcheck --leak-check=full --track-origins=yes" --vanilla < tweedie-Ex.R
?on my package example, which gives me a series of messages like this:
==53843== Conditional jump or move depends on uninitialised value(s)
==53843== at 0x1118F61FB: smallp_ (in /Users/pdunn2/Library/R/3.4/library/tweedie/libs/tweedie.so)
==53843== by 0xBFA4FB88FFFFFFEB: ???
==53843== by 0x3FF91CB2DA3A50E7: ???
==53843== by 0x104888757: ???
==53843== by 0xFFFFFFEC03E375AF: ???
==53843== by 0x3FE18C2EE1BE47CB: ???
==53843== by 0x104885DEF: ???
==53843== by 0x104885DF7: ???
==53843== by 0x3FE518F314C67BE7: ???
==53843== by 0x11364CEAF: ???
==53843== by 0x104885DBF: ???
==53843== by 0x100000007: ??? (in /Library/Frameworks/R.framework/Resources/bin/exec/R)
==53843== Uninitialised value was created by a stack allocation
==53843== at 0x1118F59A6: smallp_ (in /Users/pdunn2/Library/R/3.4/library/tweedie/libs/tweedie.so)
I can see the piece of R code in the example from which this comes. The subroutine smallp is mentioned in the second line of the output.
I simply cannot find the issue. (Spent days looking so far.) There are only a few conditional jumps, and everything not passed to the subroutine smallp is initialised. I have checked the calls to smallp as well. I have compiled the fortran code separately (after wrapping into a complete program), with all kinds of flags:
gfortran -O2 -fimplicit-none -Wall -Wline-truncation -Wcharacter-truncation -Wsurprising -Waliasing -Wunused-parameter -fwhole-file -fcheck=all -std=f2008 -pedantic -fbacktrace),
Then, using valgrind shows no errors.
So it has got to the point where I simply don?t know what else to do. I am happy to spend time looking and debugging? but I don?t know what else to do. Clearly an issue must exist, but I cannot find it.
Can anyone suggest any tools or valgrind flags or anything else that might shed light? Or ways to get more info? For example, a line number in the Fortran code where the issue first presents, or some such things? I need some pointers or strategy to make progress with tracking down the issue.
The package has been on CRAN for many years, and I have never noticed any issues with its accuracy that have not been fixed. But as it stands, I cannot update the package (which I want to do to fix an (unrelated) error).
Thanks for any advice.
P.
sessionInfo()
R version 3.4.2 (2017-09-28)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Sierra 10.12.6
Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRlapack.dylib
locale:
[1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.4.2 tools_3.4.2 yaml_2.1.14
USC, Locked Bag 4, Maroochydore DC, Queensland, 4558 Australia.
CRICOS Provider No: 01595D
Please consider the environment before printing this email.
This email is confidential. If received in error, please delete it from your system.
Hi,
2017-10-26 5:16 GMT+02:00 Peter Dunn <PDunn2 at usc.edu.au>:
Hi all
I am trying to compile (on my Mac) an R package (tweedie) which includes Fortran 77 code. I?m not much of a programmer, but can still manage to write and update F77 code. I?m new to valgrind.
In checking my package (which passes the build-and-check with no errors), I use valgrind like this:
R -d "valgrind --tool=memcheck --leak-check=full --track-origins=yes" --vanilla < tweedie-Ex.R
?on my package example, which gives me a series of messages like this:
==53843== Conditional jump or move depends on uninitialised value(s)
==53843== at 0x1118F61FB: smallp_ (in /Users/pdunn2/Library/R/3.4/library/tweedie/libs/tweedie.so)
==53843== by 0xBFA4FB88FFFFFFEB: ???
==53843== by 0x3FF91CB2DA3A50E7: ???
==53843== by 0x104888757: ???
==53843== by 0xFFFFFFEC03E375AF: ???
==53843== by 0x3FE18C2EE1BE47CB: ???
==53843== by 0x104885DEF: ???
==53843== by 0x104885DF7: ???
==53843== by 0x3FE518F314C67BE7: ???
==53843== by 0x11364CEAF: ???
==53843== by 0x104885DBF: ???
==53843== by 0x100000007: ??? (in /Library/Frameworks/R.framework/Resources/bin/exec/R)
==53843== Uninitialised value was created by a stack allocation
==53843== at 0x1118F59A6: smallp_ (in /Users/pdunn2/Library/R/3.4/library/tweedie/libs/tweedie.so)
I can see the piece of R code in the example from which this comes. The subroutine smallp is mentioned in the second line of the output.
I simply cannot find the issue. (Spent days looking so far.) There are only a few conditional jumps, and everything not passed to the subroutine smallp is initialised. I have checked the calls to smallp as well. I have compiled the fortran code separately (after wrapping into a complete program), with all kinds of flags:
gfortran -O2 -fimplicit-none -Wall -Wline-truncation -Wcharacter-truncation -Wsurprising -Waliasing -Wunused-parameter -fwhole-file -fcheck=all -std=f2008 -pedantic -fbacktrace),
Did you try "-O0 -g" instead of "-O2"?
Regards,
I?aki
Thanks for this direction.
But I am still confused, as the problem persists after attending to any possible issue: That piece of identified code only has four variables, and I can account for them all.
The two variables its and aimrerr are now explicitly initialised. So they cannot be the problem.
The variables maxit and relerr are inputs to the subroutine... and both are explicitly initialised in the only subroutine which calls smallp. So I can?t see how that can be a problem. (Clearly they cannot be initialised in the subroutine smallp or their input values are overwritten.)
Any more idea for where I should be looking, or how I can progress this? Using the flags below when gfortran is called, with -O0 ?g included, produced no errors or warnings at all.
Thanks again. I just don?t know how else to track down the error, and it?s driving me crazy.
P.
From: I?aki ?car <i.ucar86 at gmail.com>
Date: Thursday, 26 October 2017 at 7:38 pm
To: Peter Dunn <PDunn2 at usc.edu.au>
Cc: "r-package-devel at r-project.org" <r-package-devel at r-project.org>
Subject: Re: [R-pkg-devel] Package valgrind problem I can't solve: Direction?
Hi,
2017-10-26 5:16 GMT+02:00 Peter Dunn <PDunn2 at usc.edu.au>:
Hi all
I am trying to compile (on my Mac) an R package (tweedie) which includes Fortran 77 code. I?m not much of a programmer, but can still manage to write and update F77 code. I?m new to valgrind.
In checking my package (which passes the build-and-check with no errors), I use valgrind like this:
R -d "valgrind --tool=memcheck --leak-check=full --track-origins=yes" --vanilla < tweedie-Ex.R
?on my package example, which gives me a series of messages like this:
==53843== Conditional jump or move depends on uninitialised value(s)
==53843== at 0x1118F61FB: smallp_ (in /Users/pdunn2/Library/R/3.4/library/tweedie/libs/tweedie.so)
==53843== by 0xBFA4FB88FFFFFFEB: ???
==53843== by 0x3FF91CB2DA3A50E7: ???
==53843== by 0x104888757: ???
==53843== by 0xFFFFFFEC03E375AF: ???
==53843== by 0x3FE18C2EE1BE47CB: ???
==53843== by 0x104885DEF: ???
==53843== by 0x104885DF7: ???
==53843== by 0x3FE518F314C67BE7: ???
==53843== by 0x11364CEAF: ???
==53843== by 0x104885DBF: ???
==53843== by 0x100000007: ??? (in /Library/Frameworks/R.framework/Resources/bin/exec/R)
==53843== Uninitialised value was created by a stack allocation
==53843== at 0x1118F59A6: smallp_ (in /Users/pdunn2/Library/R/3.4/library/tweedie/libs/tweedie.so)
I can see the piece of R code in the example from which this comes. The subroutine smallp is mentioned in the second line of the output.
I simply cannot find the issue. (Spent days looking so far.) There are only a few conditional jumps, and everything not passed to the subroutine smallp is initialised. I have checked the calls to smallp as well. I have compiled the fortran code separately (after wrapping into a complete program), with all kinds of flags:
gfortran -O2 -fimplicit-none -Wall -Wline-truncation -Wcharacter-truncation -Wsurprising -Waliasing -Wunused-parameter -fwhole-file -fcheck=all -std=f2008 -pedantic -fbacktrace),
Did you try "-O0 -g" instead of "-O2"?
Regards,
I?aki
USC, Locked Bag 4, Maroochydore DC, Queensland, 4558 Australia.
CRICOS Provider No: 01595D
Please consider the environment before printing this email.
This email is confidential. If received in error, please delete it from your system.
2017-10-30 0:54 GMT+01:00 Peter Dunn <PDunn2 at usc.edu.au>:
Thanks for this direction.
But I am still confused, as the problem persists after attending to any
possible issue: That piece of identified code only has four variables, and I
can account for them all.
The two variables its and aimrerr are now explicitly initialised. So they
cannot be the problem.
The variables maxit and relerr are inputs to the subroutine... and both are
explicitly initialised in the only subroutine which calls smallp. So I can?t
see how that can be a problem. (Clearly they cannot be initialised in the
subroutine smallp or their input values are overwritten.)
Maybe the location is wrong. What about the "result" variable in the
"smallp" subroutine? Shouldn't it be initialised?
Any more idea for where I should be looking, or how I can progress this?
Using the flags below when gfortran is called, with -O0 ?g included,
produced no errors or warnings at all.
Given that the issue disappears depending on the optimisation level,
maybe it is a false error.
I?aki
2017-10-30 0:54 GMT+01:00 Peter Dunn <PDunn2 at usc.edu.au>:
Thanks for this direction.
But I am still confused, as the problem persists after attending to any
possible issue: That piece of identified code only has four variables, and I
can account for them all.
The two variables its and aimrerr are now explicitly initialised. So they
cannot be the problem.
The variables maxit and relerr are inputs to the subroutine... and both are
explicitly initialised in the only subroutine which calls smallp. So I can?t
see how that can be a problem. (Clearly they cannot be initialised in the
subroutine smallp or their input values are overwritten.)
Found it. "relerr" may be uninitialised because "w" is uninitialised
in smallp (tweedie 2.2.5, line 2169).
When you try to debug this kind of things, you must track not only
explicit initialisations, but also all the assignments with possibly
uninitialised variables.
BTW, I also see:
tweedie.f:335:0:
if ( funvalue .LT. exp(-lambda) ) then
Warning: 'lambda' may be used uninitialized in this function
[-Wmaybe-uninitialized]
Regards,
I?aki