LAPACK Archives

[Lapack] clapack 3.2.1: ilaenv not valgrind-clean

Dear Paul,
Thank you for reporting the issues - unfortunately CLAPACK is no longer 
maintained.
The LAPACKE C standard interface (that is include in Intel products) is the 
replacement of CLAPACK.
You can find more info here: http://www.netlib.org/lapack/lapacke.html
LAPACKE is included in the LAPACK library.
Hope it helps
Sincerely,
Julie

On Jul 31, 2014, at 1:41 PM, Paul Price <price@Domain.Removed> wrote:

Dear CLAPACK developers,

While running some code under valgrind, I noticed some errors coming from 
CLAPACK code.  I've only been able to reproduce it on a single machine in 
Japan (not on local machines!?), but in looking at the code I think the 
problem is legitimate.

I've distilled it down to a simple test case (attached test.c).

Using:
* Linux x86_64
* g++ 4.6.4
* valgrind 3.9.0

Building CLAPACK:

sed -e 's/PLAT = _LINUX/PLAT =/' -e 's/CFLAGS    = -O3/CFLAGS    = -O3 -g 
-fPIC/' -e 's/\([[:alnum:]]\{1,\}$(PLAT).a\)/lib\1/g' make.inc.example > 
make.inc
make f2clib
ln -s F2CLIBS/libf2c.a
make blaslib
cd INSTALL && make && cd ..
cd SRC && make && cd ..

Build test code:

g++ test.c -I/path/to/CLAPACK-3.2.1/INCLUDE -L/path/to/CLAPACK-3.2.1/ -o test 
-llapack -lf2c -lblas

Run test:

valgrind --tool=memcheck --log-file=valgrind.log ./test


The valgrind.log file (attached) contains multiple instances of:

==16612== Conditional jump or move depends on uninitialised value(s)
==16612==    at 0x402D6D: s_cmp (s_cmp.c:23)
==16612==    by 0x4017FC: ilaenv_ (ilaenv.c:265)
==16612==    by 0x400C43: dpotrf_ (dpotrf.c:147)
==16612==    by 0x400AB6: dposv_ (dposv.c:139)
==16612==    by 0x40091D: main (in /home/price/hsc/meas_extensions_psfex/test)

Inspecting ilaenv.c, the problem is with the variable "c2", which is set at 
line 245:

   s_copy(c2, subnam + 1, (ftnlen)1, (ftnlen)2);

This pulls the value from "subnam + 1", but "subnam" is defined (line 42) as:

   char subnam[1];

and only "subnam[0]" and not "subnam[1]" (which would be off the end) is 
initialised at line 188.

Therefore the value in c2 may indeed be uninitialised (presumably depending 
on how variables are aligned?).  No doubt c3 and c4 are as well, but since I 
don't use those values, I don't notice.

The following patch makes my test valgrind-clean:

diff --git a/SRC/ilaenv.c b/SRC/ilaenv.c
index fb07230..766dbfc 100644
--- a/SRC/ilaenv.c
+++ b/SRC/ilaenv.c
@@ -39,7 +39,7 @@ integer ilaenv_(integer *ispec, char *name__, char *opts, 
inte
    integer nbmin;
    logical sname;
    extern integer ieeeck_(integer *, real *, real *);
-    char subnam[1];
+    char subnam[8] = "\0\0\0\0\0\0\0\0";
    extern integer iparmq_(integer *, char *, char *, integer *, integer *,
            integer *, integer *);


I'm not sure if this is a bug in CLAPACK or f2c, but I would appreciate it if 
you would bring it to the attention of the appropriate people.

Thanks,

Paul.


<test.c><valgrind.log>_______________________________________________
Lapack mailing list
Lapack@Domain.Removed
http://lists.eecs.utk.edu/mailman/listinfo/lapack


<Prev in Thread] Current Thread [Next in Thread>


For additional information you may use the LAPACK/ScaLAPACK Forum.
Or one of the mailing lists, or