May 2012 - petsc-dev - mailman3.cels.anl.gov

PC defaults when matrix is not available at PCSetFromOptions
by Jed Brown 06 May '12

06 May '12

With the now-recommended approach of SNESSetDM(), a matrix is no longer available for PCGetDefaultType_Private(), so stuff like this fails: ~/petsc/src/snes/examples/tutorials$ ./ex5 -dm_mat_type sbaij [0]PETSC ERROR: --------------------- Error Message ------------------------------------ [0]PETSC ERROR: No support for this operation for this object type! [0]PETSC ERROR: Factor type not supported! [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: Petsc Development HG revision: fb0b659c7d3475598a50a3736d056cce163b2de9 HG Date: Sun Apr 15 00:02:43 2012 +0000 [0]PETSC ERROR: See docs/changes/index.html for recent updates. [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. [0]PETSC ERROR: See docs/index.html for manual pages. [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: ./ex5 on a mpich named batura by jed Sun May 6 11:25:55 2012 [0]PETSC ERROR: Libraries linked from /home/jed/petsc/mpich/lib [0]PETSC ERROR: Configure run at Tue Apr 17 15:54:40 2012 [0]PETSC ERROR: Configure options --download-ams --download-blacs --download-chaco --download-hypre --download-metis --download-ml --download-parmetis --download-spai --download-spooles --download-sundials --download-superlu --download-superlu_dist --download-triangle --with-blas-lapack=/usr --with-c2html --with-cholmod-dir=/usr --with-lgrind --with-mpi-dir=/opt/mpich2 --with-pcbddc --with-pthreadclasses --with-shared-libraries --with-single-library=0 --with-sowing --with-umfpack-dir=/usr --with-x -PETSC_ARCH=mpich [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: MatGetFactor_seqsbaij_petsc() line 1817 in /home/jed/petsc/src/mat/impls/sbaij/seq/sbaij.c [0]PETSC ERROR: MatGetFactor() line 3990 in /home/jed/petsc/src/mat/interface/matrix.c [0]PETSC ERROR: PCSetUp_ILU() line 214 in /home/jed/petsc/src/ksp/pc/impls/factor/ilu/ilu.c [0]PETSC ERROR: PCSetUp() line 832 in /home/jed/petsc/src/ksp/pc/interface/precon.c [0]PETSC ERROR: KSPSetUp() line 278 in /home/jed/petsc/src/ksp/ksp/interface/itfunc.c [0]PETSC ERROR: KSPSolve() line 402 in /home/jed/petsc/src/ksp/ksp/interface/itfunc.c [0]PETSC ERROR: SNES_KSPSolve() line 4224 in /home/jed/petsc/src/snes/interface/snes.c [0]PETSC ERROR: SNESSolve_LS() line 200 in /home/jed/petsc/src/snes/impls/ls/ls.c [0]PETSC ERROR: SNESSolve() line 3442 in /home/jed/petsc/src/snes/interface/snes.c [0]PETSC ERROR: main() line 152 in src/snes/examples/tutorials/ex5.c application called MPI_Abort(MPI_COMM_WORLD, 56) - process 0 What are the alternatives to moving matrix creation (via DM) all the way up here?

1 0

Re: [petsc-dev] MPI_Init_thread
by Jed Brown 06 May '12

06 May '12

On Sun, May 6, 2012 at 11:22 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > I could care less about MPICH2. What happens on the Cray if one switches, > sudden 50% drop in performance? Better not be.

1 0

Re: [petsc-dev] MPI_Init_thread
by Barry Smith 06 May '12

06 May '12

On May 6, 2012, at 12:19 PM, Jed Brown wrote: > On Sun, May 6, 2012 at 11:07 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Is your specific questions is: should we replace all MPI_Init() calls in PETSc with MPI_Init_thread(...,MPI_THREAD_FUNNELED,...)? > > Can't do this because of MPI-1 compatibility, but yeah, I'm thinking of always using MPI_THREAD_FUNNELED if configure picks it up. > > > Will there be a performance hit, when one is not using threads? Should we #if defined() do the replacement if the user has turned on OpenMP or Pthread or TBB only and not by default? > > Sounds like there is not likely to be a performance hit because the standard system routines are thread safe. > > http://lists.mcs.anl.gov/pipermail/mpich-discuss/2012-May/012380.html > > MPICH2 does not use POSIX functions like getchar_unlocked() or non-POSIX stuff like fwrite_unlocked(), so it seems like the library will be doing exactly the same thing in both cases. I could care less about MPICH2. What happens on the Cray if one switches, sudden 50% drop in performance? Barry

1 0

Re: [petsc-dev] MPI_Init_thread
by Jed Brown 06 May '12

06 May '12

On Sun, May 6, 2012 at 11:07 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Is your specific questions is: should we replace all MPI_Init() calls in > PETSc with MPI_Init_thread(...,MPI_THREAD_FUNNELED,...)? > Can't do this because of MPI-1 compatibility, but yeah, I'm thinking of always using MPI_THREAD_FUNNELED if configure picks it up. > > Will there be a performance hit, when one is not using threads? Should we > #if defined() do the replacement if the user has turned on OpenMP or > Pthread or TBB only and not by default? > Sounds like there is not likely to be a performance hit because the standard system routines are thread safe. http://lists.mcs.anl.gov/pipermail/mpich-discuss/2012-May/012380.html MPICH2 does not use POSIX functions like getchar_unlocked() or non-POSIX stuff like fwrite_unlocked(), so it seems like the library will be doing exactly the same thing in both cases.

1 0

Re: [petsc-dev] MPI_Init_thread
by Barry Smith 06 May '12

06 May '12

On May 6, 2012, at 11:09 AM, Jed Brown wrote: > When threading is used, PETSc should be calling MPI_Init_thread() instead of MPI_Init(). For our current use case, MPI_THREAD_FUNNELED is the natural mode to request. As opposed to MPI_THREAD_SINGLE, this causes the MPI implementation to manage locking around unsafe system calls. Should we just always ask for FUNNELED? > Is your specific questions is: should we replace all MPI_Init() calls in PETSc with MPI_Init_thread(...,MPI_THREAD_FUNNELED,...)? Will there be a performance hit, when one is not using threads? Should we #if defined() do the replacement if the user has turned on OpenMP or Pthread or TBB only and not by default? Barry > Do we envision a future time in which we want more threading (e.g. MPI_THREAD_MULTIPLE)? If so, we would definitely want a way to determine the desired mode before calling MPI_Init_thread().

1 0

MPI_Init_thread
by Jed Brown 06 May '12

06 May '12

When threading is used, PETSc should be calling MPI_Init_thread() instead of MPI_Init(). For our current use case, MPI_THREAD_FUNNELED is the natural mode to request. As opposed to MPI_THREAD_SINGLE, this causes the MPI implementation to manage locking around unsafe system calls. Should we just always ask for FUNNELED? Do we envision a future time in which we want more threading (e.g. MPI_THREAD_MULTIPLE)? If so, we would definitely want a way to determine the desired mode before calling MPI_Init_thread().

1 0

Re: [petsc-dev] Error during KSPDestroy
by Alexander Grayver 06 May '12

06 May '12

On 06.05.2012 15:34, Matthew Knepley wrote: > On Sun, May 6, 2012 at 9:24 AM, Alexander Grayver > <agrayver(a)gfz-potsdam.de <mailto:[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

1 0

Re: [petsc-dev] Error during KSPDestroy
by Matthew Knepley 06 May '12

06 May '12

On Sun, May 6, 2012 at 9:24 AM, Alexander Grayver <agrayver(a)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. Matt > ==20287== Invalid read of size 8 > ==20287== at 0x1AE79DA1: mkl_lapack_dlasq3 (in > /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_lapack.so) > ==20287== by 0x5CF7AE5: mkl_lapack_dlasq3 (in > /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_intel_thread.so) > ==20287== by 0x1AE79617: mkl_lapack_dlasq2 (in > /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_lapack.so) > ==20287== by 0x5CF7A15: mkl_lapack_dlasq2 (in > /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_intel_thread.so) > ==20287== by 0x1AA3E72A: mkl_lapack_dlasq1 (in > /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_lapack.so) > ==20287== by 0x5CF79C7: mkl_lapack_dlasq1 (in > /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_intel_thread.so) > ==20287== by 0x1AC44D6C: mkl_lapack_zbdsqr (in > /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_lapack.so) > ==20287== by 0x5CFFEF8: mkl_lapack_zbdsqr (in > /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_intel_thread.so) > ==20287== by 0x1AC7D989: mkl_lapack_zgesvd (in > /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_lapack.so) > ==20287== by 0x5D021C0: mkl_lapack_zgesvd (in > /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_intel_thread.so) > ==20287== by 0x5899E43: ZGESVD (in > /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_intel_lp64.so) > ==20287== by 0x697017: KSPComputeExtremeSingularValues_GMRES > (gmreig.c:46) > ==20287== by 0x69EFBA: KSPComputeExtremeSingularValues (itfunc.c:47) > ==20287== by 0x4509BC: main (solveTest.c:62) > ==20287== Address 0x11363d48 is not stack'd, malloc'd or (recently) free'd > > > On 06.05.2012 15:21, Alexander Grayver wrote: > > On 06.05.2012 15:07, Matthew Knepley wrote: > > Hello, >>> >>> I use KSP and random rhs to compute largest singular value: >>> >> >> 1) Is this the whole program? If not, this can be caused by memory >> corruption somewhere else. This is what I suspect. >> >> >> Matt, >> >> I can reproduce error using attached test programm and this matrix (7 mb): >> http://dl.dropbox.com/u/60982984/A.dat >> > > I run it fine with the latest petsc-dev: > > 1.405802e+00 > > Can you valgrind it on your machine? > > > I did: > valgrind --tool=memcheck -q --num-callers=20 --log-file=valgrind.log.%p > /solveTest -ksp_monitor_true_residual -log_summary -mat_type aij -ksp_rtol > 1.0e-10 -malloc off > > The error is better constrained: > > ==20287== Invalid read of size 8 > ==20287== at 0x7874B4C: opal_os_path (in > /opt/mpi/intel/openmpi-1.4.2/lib/libopen-pal.so.0.0.0) > ==20287== by 0x75F2E27: orte_session_dir_finalize (in > /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) > ==20287== by 0x76012E8: orte_errmgr_base_error_abort (in > /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) > ==20287== by 0x73396E9: ompi_mpi_abort (in > /opt/mpi/intel/openmpi-1.4.2/lib/libmpi.so.0.0.2) > ==20287== by 0x734F36E: PMPI_Abort (in > /opt/mpi/intel/openmpi-1.4.2/lib/libmpi.so.0.0.2) > ==20287== by 0x7499AB: PetscDefaultSignalHandler (signal.c:169) > ==20287== by 0x749267: PetscSignalHandler_Private (signal.c:53) > ==20287== by 0x924B9DF: ??? (in /lib64/libc-2.11.1.so) > ==20287== by 0x535D9E: VecDestroyVecs (vector.c:653) > ==20287== by 0x68B61D: KSPReset_GMRES (gmres.c:258) > ==20287== by 0x6A9D39: KSPReset (itfunc.c:733) > ==20287== by 0x6AA839: KSPDestroy (itfunc.c:780) > ==20287== by 0x4509F8: main (solveTest.c:66) > ==20287== Address 0xbde4860 is 0 bytes inside a block of size 2 alloc'd > ==20287== at 0x4C26B9B: malloc (vg_replace_malloc.c:263) > ==20287== by 0x92876DF: vasprintf (in /lib64/libc-2.11.1.so) > ==20287== by 0x9266C67: asprintf (in /lib64/libc-2.11.1.so) > ==20287== by 0x75F1701: orte_util_convert_vpid_to_string (in > /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) > ==20287== by 0x75F2D4A: orte_session_dir_finalize (in > /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) > ==20287== by 0x76012E8: orte_errmgr_base_error_abort (in > /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) > ==20287== by 0x73396E9: ompi_mpi_abort (in > /opt/mpi/intel/openmpi-1.4.2/lib/libmpi.so.0.0.2) > ==20287== by 0x734F36E: PMPI_Abort (in > /opt/mpi/intel/openmpi-1.4.2/lib/libmpi.so.0.0.2) > ==20287== by 0x7499AB: PetscDefaultSignalHandler (signal.c:169) > ==20287== by 0x749267: PetscSignalHandler_Private (signal.c:53) > ==20287== by 0x924B9DF: ??? (in /lib64/libc-2.11.1.so) > ==20287== by 0x535D9E: VecDestroyVecs (vector.c:653) > ==20287== by 0x68B61D: KSPReset_GMRES (gmres.c:258) > ==20287== by 0x6A9D39: KSPReset (itfunc.c:733) > ==20287== by 0x6AA839: KSPDestroy (itfunc.c:780) > ==20287== by 0x4509F8: main (solveTest.c:66) > > Full log is attached. > > Important. > If I comment this line: > KSPComputeExtremeSingularValues(ksp, &maxx, &minx); > > It works. > > -- > > 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

1 0

Re: [petsc-dev] Error during KSPDestroy
by Alexander Grayver 06 May '12

06 May '12

Hm, valgrind gives a lot of output like that (see full log in previous message): ==20287== Invalid read of size 8 ==20287== at 0x1AE79DA1: mkl_lapack_dlasq3 (in /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_lapack.so) ==20287== by 0x5CF7AE5: mkl_lapack_dlasq3 (in /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_intel_thread.so) ==20287== by 0x1AE79617: mkl_lapack_dlasq2 (in /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_lapack.so) ==20287== by 0x5CF7A15: mkl_lapack_dlasq2 (in /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_intel_thread.so) ==20287== by 0x1AA3E72A: mkl_lapack_dlasq1 (in /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_lapack.so) ==20287== by 0x5CF79C7: mkl_lapack_dlasq1 (in /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_intel_thread.so) ==20287== by 0x1AC44D6C: mkl_lapack_zbdsqr (in /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_lapack.so) ==20287== by 0x5CFFEF8: mkl_lapack_zbdsqr (in /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_intel_thread.so) ==20287== by 0x1AC7D989: mkl_lapack_zgesvd (in /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_lapack.so) ==20287== by 0x5D021C0: mkl_lapack_zgesvd (in /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_intel_thread.so) ==20287== by 0x5899E43: ZGESVD (in /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_intel_lp64.so) ==20287== by 0x697017: KSPComputeExtremeSingularValues_GMRES (gmreig.c:46) ==20287== by 0x69EFBA: KSPComputeExtremeSingularValues (itfunc.c:47) ==20287== by 0x4509BC: main (solveTest.c:62) ==20287== Address 0x11363d48 is not stack'd, malloc'd or (recently) free'd On 06.05.2012 15:21, Alexander Grayver wrote: > On 06.05.2012 15:07, Matthew Knepley wrote: >> >>> Hello, >>> >>> I use KSP and random rhs to compute largest singular value: >>> >>> >>> 1) Is this the whole program? If not, this can be caused by >>> memory corruption somewhere else. This is what I suspect. >> >> Matt, >> >> I can reproduce error using attached test programm and this >> matrix (7 mb): >> http://dl.dropbox.com/u/60982984/A.dat >> >> >> I run it fine with the latest petsc-dev: >> >> 1.405802e+00 >> >> Can you valgrind it on your machine? >> > > I did: > valgrind --tool=memcheck -q --num-callers=20 > --log-file=valgrind.log.%p /solveTest -ksp_monitor_true_residual > -log_summary -mat_type aij -ksp_rtol 1.0e-10 -malloc off > > The error is better constrained: > > ==20287== Invalid read of size 8 > ==20287== at 0x7874B4C: opal_os_path (in > /opt/mpi/intel/openmpi-1.4.2/lib/libopen-pal.so.0.0.0) > ==20287== by 0x75F2E27: orte_session_dir_finalize (in > /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) > ==20287== by 0x76012E8: orte_errmgr_base_error_abort (in > /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) > ==20287== by 0x73396E9: ompi_mpi_abort (in > /opt/mpi/intel/openmpi-1.4.2/lib/libmpi.so.0.0.2) > ==20287== by 0x734F36E: PMPI_Abort (in > /opt/mpi/intel/openmpi-1.4.2/lib/libmpi.so.0.0.2) > ==20287== by 0x7499AB: PetscDefaultSignalHandler (signal.c:169) > ==20287== by 0x749267: PetscSignalHandler_Private (signal.c:53) > ==20287== by 0x924B9DF: ??? (in /lib64/libc-2.11.1.so) > ==20287== by 0x535D9E: VecDestroyVecs (vector.c:653) > ==20287== by 0x68B61D: KSPReset_GMRES (gmres.c:258) > ==20287== by 0x6A9D39: KSPReset (itfunc.c:733) > ==20287== by 0x6AA839: KSPDestroy (itfunc.c:780) > ==20287== by 0x4509F8: main (solveTest.c:66) > ==20287== Address 0xbde4860 is 0 bytes inside a block of size 2 alloc'd > ==20287== at 0x4C26B9B: malloc (vg_replace_malloc.c:263) > ==20287== by 0x92876DF: vasprintf (in /lib64/libc-2.11.1.so) > ==20287== by 0x9266C67: asprintf (in /lib64/libc-2.11.1.so) > ==20287== by 0x75F1701: orte_util_convert_vpid_to_string (in > /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) > ==20287== by 0x75F2D4A: orte_session_dir_finalize (in > /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) > ==20287== by 0x76012E8: orte_errmgr_base_error_abort (in > /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) > ==20287== by 0x73396E9: ompi_mpi_abort (in > /opt/mpi/intel/openmpi-1.4.2/lib/libmpi.so.0.0.2) > ==20287== by 0x734F36E: PMPI_Abort (in > /opt/mpi/intel/openmpi-1.4.2/lib/libmpi.so.0.0.2) > ==20287== by 0x7499AB: PetscDefaultSignalHandler (signal.c:169) > ==20287== by 0x749267: PetscSignalHandler_Private (signal.c:53) > ==20287== by 0x924B9DF: ??? (in /lib64/libc-2.11.1.so) > ==20287== by 0x535D9E: VecDestroyVecs (vector.c:653) > ==20287== by 0x68B61D: KSPReset_GMRES (gmres.c:258) > ==20287== by 0x6A9D39: KSPReset (itfunc.c:733) > ==20287== by 0x6AA839: KSPDestroy (itfunc.c:780) > ==20287== by 0x4509F8: main (solveTest.c:66) > > Full log is attached. > > Important. > If I comment this line: > KSPComputeExtremeSingularValues(ksp, &maxx, &minx); > > It works. > > -- > Regards, > Alexander -- Regards, Alexander

1 0

Re: [petsc-dev] Error during KSPDestroy
by Alexander Grayver 06 May '12

06 May '12

On 06.05.2012 15:07, Matthew Knepley wrote: > >> Hello, >> >> I use KSP and random rhs to compute largest singular value: >> >> >> 1) Is this the whole program? If not, this can be caused by >> memory corruption somewhere else. This is what I suspect. > > Matt, > > I can reproduce error using attached test programm and this matrix > (7 mb): > http://dl.dropbox.com/u/60982984/A.dat > > > I run it fine with the latest petsc-dev: > > 1.405802e+00 > > Can you valgrind it on your machine? > I did: valgrind --tool=memcheck -q --num-callers=20 --log-file=valgrind.log.%p /solveTest -ksp_monitor_true_residual -log_summary -mat_type aij -ksp_rtol 1.0e-10 -malloc off The error is better constrained: ==20287== Invalid read of size 8 ==20287== at 0x7874B4C: opal_os_path (in /opt/mpi/intel/openmpi-1.4.2/lib/libopen-pal.so.0.0.0) ==20287== by 0x75F2E27: orte_session_dir_finalize (in /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) ==20287== by 0x76012E8: orte_errmgr_base_error_abort (in /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) ==20287== by 0x73396E9: ompi_mpi_abort (in /opt/mpi/intel/openmpi-1.4.2/lib/libmpi.so.0.0.2) ==20287== by 0x734F36E: PMPI_Abort (in /opt/mpi/intel/openmpi-1.4.2/lib/libmpi.so.0.0.2) ==20287== by 0x7499AB: PetscDefaultSignalHandler (signal.c:169) ==20287== by 0x749267: PetscSignalHandler_Private (signal.c:53) ==20287== by 0x924B9DF: ??? (in /lib64/libc-2.11.1.so) ==20287== by 0x535D9E: VecDestroyVecs (vector.c:653) ==20287== by 0x68B61D: KSPReset_GMRES (gmres.c:258) ==20287== by 0x6A9D39: KSPReset (itfunc.c:733) ==20287== by 0x6AA839: KSPDestroy (itfunc.c:780) ==20287== by 0x4509F8: main (solveTest.c:66) ==20287== Address 0xbde4860 is 0 bytes inside a block of size 2 alloc'd ==20287== at 0x4C26B9B: malloc (vg_replace_malloc.c:263) ==20287== by 0x92876DF: vasprintf (in /lib64/libc-2.11.1.so) ==20287== by 0x9266C67: asprintf (in /lib64/libc-2.11.1.so) ==20287== by 0x75F1701: orte_util_convert_vpid_to_string (in /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) ==20287== by 0x75F2D4A: orte_session_dir_finalize (in /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) ==20287== by 0x76012E8: orte_errmgr_base_error_abort (in /opt/mpi/intel/openmpi-1.4.2/lib/libopen-rte.so.0.0.0) ==20287== by 0x73396E9: ompi_mpi_abort (in /opt/mpi/intel/openmpi-1.4.2/lib/libmpi.so.0.0.2) ==20287== by 0x734F36E: PMPI_Abort (in /opt/mpi/intel/openmpi-1.4.2/lib/libmpi.so.0.0.2) ==20287== by 0x7499AB: PetscDefaultSignalHandler (signal.c:169) ==20287== by 0x749267: PetscSignalHandler_Private (signal.c:53) ==20287== by 0x924B9DF: ??? (in /lib64/libc-2.11.1.so) ==20287== by 0x535D9E: VecDestroyVecs (vector.c:653) ==20287== by 0x68B61D: KSPReset_GMRES (gmres.c:258) ==20287== by 0x6A9D39: KSPReset (itfunc.c:733) ==20287== by 0x6AA839: KSPDestroy (itfunc.c:780) ==20287== by 0x4509F8: main (solveTest.c:66) Full log is attached. Important. If I comment this line: KSPComputeExtremeSingularValues(ksp, &maxx, &minx); It works. -- Regards, Alexander

1 0