Some tests fail in Mac OS X 10.7.5 compiling with gfortran 4.8.4 about arpack-ng HOT 15 CLOSED

Hello,

I am seeing these segfaults with intel 2016 update 4 on centos 7. Apparently it tries to link against the lapack and blas libraries from the OS (-llapack -lblas everywhere). If the MKL is passed via LDFLAGS (and configure detects sgemm succesfully in it) it even gets ignored later. It still links all tests against -llapack -lblas.

Changing the libraries in every single makefile so that the testers/examples link only against the MKL (and nothing else !) makes the segfaults go away. All tests pass then.

So. please rethink you build assumptions and testers. If I build that library with the intel compilers I of course want to use them later in production together with the MKL and that combination is what I want to test. For a numerical performance library being able to select the blas/lapack libraries cleanly at configure time (regardless whether MKL, openblas or atlas) is a must.

Best Regards

Christof

from arpack-ng.

A backtrace with the debugging symbols would help.

from arpack-ng.

cnbdr3 segfault

(gdb) run
Starting program: /Users/terron/tmp/octave-build/arpack-ng-3.1.5/EXAMPLES/BAND/.libs/cnbdr3
Reading symbols for shared libraries ++++++............................ done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000031961d310
0x00007fff86d7f257 in cblas_cdotc_sub ()
(gdb) bt
#0 0x00007fff86d7f257 in cblas_cdotc_sub ()
#1 0x000000010019c462 in cgetv0_ ()
#2 0x000000040000000a in ?? ()
(gdb) list
291 c %-------------------------------------%
292 c
293 print *, ' '
294 print *, ' Error with _band, info= ', info
295 print *, ' Check the documentation of band '
296 print *, ' '
297 c
298 end if
299 c
300 9000 end
(gdb) bt
#0 0x00007fff86d7f257 in cblas_cdotc_sub ()
#1 0x000000010019c462 in cgetv0 ()
#2 0x000000040000000a in ?? ()
(gdb)

znbdr1

(gdb) run
Starting program: /Users/terron/tmp/octave-build/arpack-ng-3.1.5/EXAMPLES/BAND/.libs/znbdr1
Reading symbols for shared libraries ++++++............................ done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000000000000b
0x00007fff86885d9a in zdotc_ ()
(gdb) bt
#0 0x00007fff86885d9a in zdotc_ ()
#1 0x000000010036eb67 in zneupd_ ()

znbdr2

(gdb) run
Starting program: /Users/terron/tmp/octave-build/arpack-ng-3.1.5/EXAMPLES/BAND/.libs/znbdr2
Reading symbols for shared libraries ++++++............................ done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000000000000b
0x00007fff86885d9a in zdotc_ ()
(gdb) bt
#0 0x00007fff86885d9a in zdotc_ ()
#1 0x000000010036eb67 in zneupd_ ()

znbd3

(gdb) run
Starting program: /Users/terron/tmp/octave-build/arpack-ng-3.1.5/EXAMPLES/BAND/.libs/znbdr3
Reading symbols for shared libraries ++++++............................ done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000001
0x00007fff86885d9a in zdotc_ ()
(gdb) bt
#0 0x00007fff86885d9a in zdotc_ ()
#1 0x0000000100368cd6 in znaitr_ ()

from arpack-ng.

Seems Mac OS X related to me ( cblas_cdotc_sub comes from Mac OS X)
https://developer.apple.com/library/mac/documentation/Accelerate/Reference/BLAS_Ref/index.html#//apple_ref/c/func/cblas_cdotc_sub

Not sure it is arpack-ng's fault

from arpack-ng.

i have similar SEGV when compiling with MKL (as opposed to framework Accelerate) on OS-X

FAIL: cnbdr1
============


Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x10fc84132
#1  0x10fc83450
#2  0x7fff91eccea9
#3  0x10c54c733
#4  0x10c4cc005
#5  0x10c2fd266
#6  0x10c2fba87
#7  0x10c2fd419
FAIL cnbdr1 (exit status: 139)

FAIL: cnbdr2
============


Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x10bf5e132
#1  0x10bf5d450
#2  0x7fff91eccea9
#3  0x108824733
#4  0x1087a8005
#5  0x1085da266
#6  0x1085d8a87
#7  0x1085da419
FAIL cnbdr2 (exit status: 139)

FAIL: cnbdr3
============


Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x1078c4132
#1  0x1078c3450
#2  0x7fff91eccea9
FAIL cnbdr3 (exit status: 139)

FAIL: znbdr1
============


Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x10c12e132
#1  0x10c12d450
#2  0x7fff91eccea9
FAIL znbdr1 (exit status: 139)

FAIL: znbdr2
============


Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x10c993132
#1  0x10c992450
#2  0x7fff91eccea9
FAIL znbdr2 (exit status: 139)

from arpack-ng.

I believe these failures are due to the mixing of different fortran calling conventions between gfortran compiled arpack and Apple BLAS / MKL using a different one.

from arpack-ng.

Hello,

I have to correct this. During configure the MKL is not detected. $MKLROOT etc. is set correctly, though, and we do not have problems with other builds. It is passed as
LDFALGS="-L${MKLROOT}/lib/intel64".

Not being able to set the lapack/blas libraries in a reliable way is not good, especially if it leads to tester segfaults.

Best Regards

Christof

from arpack-ng.

@ckoe-bccms if you use CMake, it should work with

-DLAPACK_FOUND=true,
-DLAPACK_INCLUDE_DIRS=/path/to/mkl/include,
-DLAPACK_LIBRARIES=mkl_rt
-DBLAS_FOUND=true,
-DBLAS_INCLUDE_DIRS=/path/to/mkl/include,
-DBLAS_LIBRARIES=mkl_rt

or you can specify interface and threading layers manually.

from arpack-ng.

Hello,

that may be. I have to admit that my experience with cmake is limited. However, my complaint (as the original one) was that it does not work (reliably ?) with configure.

May I assume from the facts that at the moment both cmake and configure are offered and that you tell me that it works with cmake that you in fact want to (or can only) support cmake only at some point ? If so it might be helpful if building with configure would be documented as deprecated.

Best Regards

Christof

from arpack-ng.

that you tell me that it works with cmake that you in fact want to (or can only) support cmake only at some point ?

to be clear, I am NOT a developer of Arpack. I contributed a few small patches, but otherwise I am not involved in it's development/support.

from arpack-ng.

Hello,

yes, I notice that there are quite a number of git repos of some "arpack-ng". So, is this the entirely wrong repo ?

Some more points anyway with respect to the original issue (in case any developer is interested):

FC=ifort FCFLAGS="-O2 -fp-model source" CC=icc CFLAGS="-O2 -fp-model source" F77=ifort FFLAGS="-O2 -fp-model source" LDFALGS="-L${MKLROOT}/lib/intel64" LIBS="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl" ./configure --prefix=/cluster/arpack-ng/3.5.0/intel-2016

gives

checking whether the Fortran compiler works... no
configure: error: in `/home1/ckoe/src/arpack-ng':
configure: error: Fortran compiler cannot create executables

because of

configure:3075: checking whether the Fortran compiler works
configure:3097: ifort -O2 -fp-model source conftest.f -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl >&5
ld: cannot find -lmkl_intel_lp64
ld: cannot find -lmkl_intel_thread
ld: cannot find -lmkl_core

So LDFLAGS is not passed at all. May be I messed up the configure options, but I cannot find the error.

Now, I check this with gcc and openblas
LDFALGS="/cluster/OpenBLAS/0.2.19/gcc62/lib" LIBS="-lopenblas_omp" ./configure

configure: error: Fortran compiler cannot create executables

configure:3097: gfortran conftest.f -lopenblas_omp >&5
/usr/bin/ld: cannot find -lopenblas_omp
collect2: error: ld returned 1 exit status

So again, LDFLAGS is not passed.

Note that this built has "_omp" attached to the library name to distinguish it from a non-threaded built (this is a standard setting in the openblas Make.rules file) so the standard test for -lopenblas, i.e. not setting LIBS, would never find it.

This built system appears to be broken at the moment.

Best regards

Christof

from arpack-ng.

Hello again,

of course I messed this up. It is LDFLAGS nor LDFALGS ... Then it succesfully detects the libraries.

Sorry for the noise ! My apologies.

Best Regards

Christof

from arpack-ng.

I notice that there are quite a number of git repos of some "arpack-ng".

no, this is entirely correct repo 😄 I am just saying that I myself is NOT a maintainer of this repository, but only an infrequent contributor.

from arpack-ng.

Mixing using libraries complied by different compiler would cause serious problems.
If BLAS and LAPACK is complied by ifort, when compile arpack-ng, you also need to use ifort.
If you are using cmake, add the options of -DBLAS_LIBRARIES and -DLAPACK_LIBRARIES to indicate the specific BLAS and LAPACK libraries you want to use.

from arpack-ng.

@cterron : if you could install or build BLAS / LAPACK providing iso_c_binding API (ICB) on Mac OS X, you may get build + all tests OK (even mixing compilers which is not recommended anyway). If so, report how (not used to Mac) to improve CI here

Quick look at https://github.com/Reference-LAPACK/lapack : with cmake, if CBLAS or LAPACKE options could end-up with ICB API (?), then try to compile LAPACK/BLAS this way, and then, try to build / test arpack-ng with these LAPACK/BLAS. Seems LAPACK does not support ICB git grep -i iso_c show no hit : best chance left would be trying to impose type sizes compiling LAPACK/BLAS with -fdefault-double-8 and / or friends...

from arpack-ng.