[petsc-dev] Error during KSPDestroy

[Barry Smith]

   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>