Skip to content

Conditional jump or move depends on uninitialised value(s)

2 messages · Jarrod Hadfield, Brian Ripley

Original
Jarrod Hadfield
# 
Hi,

I'm using valgrind to check over some C/C++ code for an R library. I'm  
getting the report (see below), but can't track down the uninitialised  
value(s). I tried using  --track-origins=yes in valgrind which gives:

==28258==  Uninitialised value was created by a stack allocation
==28258==    at 0xEE33D98: ??? (in /usr/lib64/R/lib/libRlapack.so)

I presume the problem is an uninitialised value being used in my code,  
rather than in libRlapack, but there is a better way of tracking down  
where it is?

Cheers,

Jarrod
==28258== Conditional jump or move depends on uninitialised value(s)
==28258==    at 0xEE87208: dstemr_ (in /usr/lib64/R/lib/libRlapack.so)
==28258==    by 0xEE7F39B: dsyevr_ (in /usr/lib64/R/lib/libRlapack.so)
==28258==    by 0x15B23BD9: ??? (in /usr/lib64/R/modules/lapack.so)
==28258==    by 0x15B28397: ??? (in /usr/lib64/R/modules/lapack.so)
==28258==    by 0x35CA4BFEAC: ??? (in /usr/lib64/R/lib/libR.so)
==28258==    by 0x35CA4C8A1F: Rf_eval (in /usr/lib64/R/lib/libR.so)
==28258==    by 0x35CA4BB310: Rf_applyClosure (in /usr/lib64/R/lib/libR.so)
==28258==    by 0x35CA4C58F9: ??? (in /usr/lib64/R/lib/libR.so)
==28258==    by 0x35CA4C8A1F: Rf_eval (in /usr/lib64/R/lib/libR.so)
==28258==    by 0x35CA4BB310: Rf_applyClosure (in /usr/lib64/R/lib/libR.so)
==28258==    by 0x35CA4C8ACC: Rf_eval (in /usr/lib64/R/lib/libR.so)
==28258==    by 0x35CA4CAEE7: ??? (in /usr/lib64/R/lib/libR.so)
==28258==  Uninitialised value was created by a stack allocation
==28258==    at 0xEE33D98: ??? (in /usr/lib64/R/lib/libRlapack.so)
Brian Ripley
#
On 14/03/2014 17:56, Jarrod Hadfield wrote:
R package?
You need debug symbols.  Maybe available for your unstated platform, or 
build a version of R with an internal LAPACK.

I doubt this is you: 'Writing R Extensions' has

'Note that memory access errors may be seen with LAPACK, BLAS and 
Java-using packages: some at least of these seem to be intentional, and 
some are related to passing characters to Fortran.'

Also, it is entirely possible that this is a non-current version of 
LAPACK: quite a few things like this have been plugged recently.  For 
example, Fedora currently has 3.4.2 and 3.5.0 has been out for a lot 
longer than Fedora 20.