On 06.05.2012 22:24, Barry Smith wrote:
Alexander,
I cannot reproduce this on my mac with 3 different blas/lapack.
Barry,
I'm surprised. I ran it on my home PC with ubuntu and PETSc configured from scratch as following:
--download-mpich --with-fortran-interfaces=1 --download-scalapack --download-blacs --with-scalar-type=complex --download-blas-lapack --with-precision=double
And it's still there.
Please note that all my numbers are complex.
I just ran this with complex instead of real. I get
and no crash.
Matt
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.
I did:
./configure --with-petsc-arch=openmpi-intel-complex-debug-c --download-scalapack --download-blacs --download-f-blas-lapack --with-precision=double --with-scalar-type=complex
And then valgrind program. The first message from log:
==27656== Invalid write of size 8
==27656== at 0x15A8E9E: dlasq2_ (dlasq2.f:215)
==27656== by 0x15A83A4: dlasq1_ (dlasq1.f:135)
==27656== by 0x158ACEC: zbdsqr_ (zbdsqr.f:225)
==27656== by 0x154EC27: zgesvd_ (zgesvd.f:2038)
==27656== by 0x695DD3: KSPComputeExtremeSingularValues_GMRES (gmreig.c:46)
==27656== by 0x69DD76: KSPComputeExtremeSingularValues (itfunc.c:47)
==27656== by 0x44E98C: main (solveTest.c:62)
==27656== Address 0xfad2d98 is 8 bytes before a block of size 832 alloc'd
==27656== at 0x4C25D66: memalign (vg_replace_malloc.c:694)
==27656== by 0x4B642B: PetscMallocAlign (mal.c:30)
==27656== by 0x687775: KSPSetUp_GMRES (gmres.c:73)
==27656== by 0x69FE4A: KSPSetUp (itfunc.c:239)
==27656== by 0x6A2058: KSPSolve (itfunc.c:402)
==27656== by 0x44E969: main (solveTest.c:61)
Please find full log attached.
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<agrayver@gfz-potsdam.de> 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
--
Regards,
Alexander