I am also running complex.
Look in the file dlasq2.f (it will be in the externalpackages subdirectory
of the PETSc directory. Look at line 215, this is where valgrind has a problem.
In my copy
END IF
*
* Check for negative data and compute sums of q's and e's.
*
<------ this is line 215
Z( 2*N ) = ZERO
it is a comment, which is not good. Is lione 215 also a comment in your copy of
dlasq2.f?
There are two possible causes I can think of for your problem
1) PETSc does not allocate enough work space for zgesvd() or
2) the BLAS/LAPACK routines have a bug where they sometimes access out of their
work space.
Satish,
Can you try the same build options on a Linux machine as close to
Alexander as we have and see if you can reproduce this?
Barry
On May 7, 2012, at 2:16 AM, Alexander Grayver wrote:
> 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.
>
>> 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 at
>>>> 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
>
> <valgrind.zip>
