[petsc-dev] Error during KSPDestroy

[Matthew Knepley]

On Mon, May 7, 2012 at 3:16 AM, Alexander Grayver
<agrayver at gfz-potsdam.de>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.
>

I just ran this with complex instead of real. I get

sh: 1.688716e+00

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: KSPComputeExtremeSingularValue**s_GMRES
> (gmreig.c:46)
> ==27656==    by 0x69DD76: KSPComputeExtremeSingularValue**s (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 <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: KSPComputeExtremeSingularValue**s_GMRES
>>> (gmreig.c:46)
>>> ==13600==    by 0x69C62A: KSPComputeExtremeSingularValue**s
>>> (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
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120507/e907f176/attachment.html>