10.0-10.2 dsyevr / dstegr segfaults with em64t & dynamic library combination

[ssakuraba2]

Hi,

I found the following program segfaults with an attached file (reproduce1.c).

Curiously, if I link MKL statically, the program runs without an error. I guess that something is wrong with dynamic loading.

I don't know whether this is bug or not, but perhaps this is a duplicate of previously reported issue:
http://software.intel.com/en-us/forums/showthread.php?t=66776

I use ubuntu 8.04, 64 bit version on Core2Q6600. The same phenomena were observed with MKL 10.0 - 10.2.1.

% uname -a

Linux foo 2.6.24-24-generic #1 SMP Fri Jul 24 22:15:50 UTC 2009 x86_64 GNU/Linux

% icc -g reproduce1.c -L/opt/intel/mkl/10.2.1.017/lib -lmkl_intel_lp64 -lmkl_core -lmkl_sequential -lm

% ./a.out

zsh: segmentation fault ./a.out
% valgrind ./a.out

(snip)

==525== Invalid read of size 8
==525== at 0x4015EE4: (within /lib/ld-2.7.so)
==525== by 0x400AB93: (within /lib/ld-2.7.so)
==525== by 0x40061E4: (within /lib/ld-2.7.so)
==525== by 0x4008677: (within /lib/ld-2.7.so)
==525== by 0x4012048: (within /lib/ld-2.7.so)
==525== by 0x400DDF5: (within /lib/ld-2.7.so)
==525== by 0x401191A: (within /lib/ld-2.7.so)
==525== by 0x6688F8A: (within /lib/libdl-2.7.so)
==525== by 0x400DDF5: (within /lib/ld-2.7.so)
==525== by 0x66894EC: (within /lib/libdl-2.7.so)
==525== by 0x6688EF0: dlopen (in /lib/libdl-2.7.so)
==525== by 0x522CC0C: mkl_serv_load_lapack_dll (in /opt/intel/mkl/10.2.1.017/lib/em64t/libmkl_core.so)
==525== Address 0x688c118 is 48 bytes inside a block of size 53 alloc'd
==525== at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
==525== by 0x4005F47: (within /lib/ld-2.7.so)
==525== by 0x400885F: (within /lib/ld-2.7.so)
==525== by 0x4012048: (within /lib/ld-2.7.so)
==525== by 0x400DDF5: (within /lib/ld-2.7.so)
==525== by 0x401191A: (within /lib/ld-2.7.so)
==525== by 0x6688F8A: (within /lib/libdl-2.7.so)
==525== by 0x400DDF5: (within /lib/ld-2.7.so)
==525== by 0x66894EC: (within /lib/libdl-2.7.so)
==525== by 0x6688EF0: dlopen (in /lib/libdl-2.7.so)
==525== by 0x522CC0C: mkl_serv_load_lapack_dll (in /opt/intel/mkl/10.2.1.017/lib/em64t/libmkl_core.so)
==525== by 0x527884A: mkl_lapack_dsyevr (in /opt/intel/mkl/10.2.1.017/lib/em64t/libmkl_core.so)
==525==
==525== Invalid read of size 8
==525== at 0x70CB452: mkl_lapack_dlar1v (in /opt/intel/mkl/10.2.1.017/lib/em64t/libmkl_lapack.so)
==525== by 0x52714FE: mkl_lapack_dlar1v (in /opt/intel/mkl/10.2.1.017/lib/em64t/libmkl_core.so)
==525== by 0x70D9202: mkl_lapack_dlarrv (in /opt/intel/mkl/10.2.1.017/lib/em64t/libmkl_lapack.so)
==525== by 0x5271EB4: mkl_lapack_dlarrv (in /opt/intel/mkl/10.2.1.017/lib/em64t/libmkl_core.so)
==525== by 0x718266A: mkl_lapack_dstemr (in /opt/intel/mkl/10.2.1.017/lib/em64t/libmkl_lapack.so)
==525== by 0x52780D4: mkl_lapack_dstemr (in /opt/intel/mkl/10.2.1.017/lib/em64t/libmkl_core.so)
==525== by 0x7129193: mkl_lapack_dsyevr (in /opt/intel/mkl/10.2.1.017/lib/em64t/libmkl_lapack.so)
==525== by 0x5278832: mkl_lapack_dsyevr (in /opt/intel/mkl/10.2.1.017/lib/em64t/libmkl_core.so)
==525== by 0x4F767BE: DSYEVR (in /opt/intel/mkl/10.2.1.017/lib/em64t/libmkl_intel_lp64.so)
==525== by 0x400AF3: main (reproduce1.c:77)
==525== Address 0xef8538e067ad3800 is not stack'd, malloc'd or (recently) free'd

(snip)

% icc -g reproduce1.c -L/opt/intel/mkl/10.2.1.017/lib -Wl,--start-group $MKLPATH/libmkl_intel_lp64.a $MKLPATH/libmkl_sequential.a $MKLPATH/libmkl_core.a -Wl,--end-group

% ./a.out

Eigenvalues: -0.623475 -0.000000 9.623475
Eigenvectors:
(0.827671 0.142414 -0.542844)
(0.408248 -0.816497 0.408248)
(-0.385090 -0.559510 -0.733931)
%

If I use dsyev instead of dsyevr (by passing arguments to program, see line 43), it works fine. Other functions like dsyrk, dgemv, dgemm make no problems, as far as I could confirm. Only dsyevr gets error on dynamic loading.

(edit: changed linking option for static version to be compatible with dynamic version. Result is the same.)
(edit: commented about dsyev and other functions)

[TimP]

The library path you show for your link doesn't match the path shown for the .so files in your log. If you don't use the same .so for link and run time, that could explain the problem. I would guess the -L designation in your static link is ignored.
An advantage of the Intel "professional" compiler editions is the automatic inclusion of MKL paths in the compiler path setup.

[ssakuraba2]

Thanks for pointing out. The problem still remains after changing it to correct path.

I am using mklvarsem64t.sh, thus actually there were no need to add -L paths. I just wanted to add it so that the command line be the same as written in reference manual. Sorry for making confusion.

Quoting - tim18

The library path you show for your link doesn't match the path shown for the .so files in your log. If you don't use the same .so for link and run time, that could explain the problem. I would guess the -L designation in your static link is ignored.
An advantage of the Intel "professional" compiler editions is the automatic inclusion of MKL paths in the compiler path setup.

[Todd_R_Intel · Accepted solution]

This is a known issue. It has been fixed in an update which will be released soon. I don't know of any workaround other than linking statically.
-Todd