Alexander, I cannot reproduce this on my mac with 3 different blas/lapack. Could you please run the case below but with --download-f-blas-lapack (you forgot the -f last time)? Send us the valgrind results. This will tell use the exact line number in dlasq3() that is triggering the bad read. Barry On May 6, 2012, at 9:16 AM, Alexander Grayver wrote:

On 06.05.2012 15:34, Matthew Knepley wrote:

...

On Sun, May 6, 2012 at 9:24 AM, Alexander Grayver <[email protected]> wrote: Hm, valgrind gives a lot of output like that (see full log in previous message):

Can you run this with --download-f-blas-lapack? This sounds much more like an MKL bug.

I did: --download-scalapack --download-blacs --download-blas-lapack --with-precision=double --with-scalar-type=complex

The error is still there. I checked "ldd solveTest", mkl is not used for sure. This is not an MKL problem I guess:

==13600== Invalid read of size 8 ==13600== at 0x58636AF: dlasq3_ (in /usr/local/lib/liblapack.so.3.2.2) ==13600== by 0x5862C84: dlasq2_ (in /usr/local/lib/liblapack.so.3.2.2) ==13600== by 0x5861F2C: dlasq1_ (in /usr/local/lib/liblapack.so.3.2.2) ==13600== by 0x571A479: zbdsqr_ (in /usr/local/lib/liblapack.so.3.2.2) ==13600== by 0x57466A7: zgesvd_ (in /usr/local/lib/liblapack.so.3.2.2) ==13600== by 0x694687: KSPComputeExtremeSingularValues_GMRES (gmreig.c:46) ==13600== by 0x69C62A: KSPComputeExtremeSingularValues (itfunc.c:47) ==13600== by 0x44E02C: main (solveTest.c:62) ==13600== Address 0x10826b90 is 16 bytes before a block of size 832 alloc'd ==13600== at 0x4C25D66: memalign (vg_replace_malloc.c:694) ==13600== by 0x4B5ACB: PetscMallocAlign (mal.c:30) ==13600== by 0x686181: KSPSetUp_GMRES (gmres.c:73) ==13600== by 0x69E6FE: KSPSetUp (itfunc.c:239) ==13600== by 0x6A090C: KSPSolve (itfunc.c:402) ==13600== by 0x44E009: main (solveTest.c:61)

The weird thing is that the it gives correct result, so zgesvd works fine.

And also running this program with 10 iterations in valgrind doesn't produce error. The low above is with 100 iterations. Without valgrind the error is always there.

-- Regards, Alexander