Export to GitHub

blopex - issue #3

unallocated memory if orthonormalization fails - possible memory leak


Posted on Feb 1, 2011 by Happy Ox

What steps will reproduce the problem? 1. call lobpcg_solve_double 2. if orthonormalization fails with DPOTRF INFO = 9 3. there seems to stay unallocated memory at exit

What is the expected output? What do you see instead? Within our solver, we solve several thousands of independent generalized eigenproblems, resulting in the same number of calls to LOBPCG. Quite often, LOBPCG exits with nonzero return code. This is not a big issue as we use it only to improve our solver setup and a failure in LOBPCG is not a reason for us to terminate the whole execution. However, it seems that there is some unallocated memory any time this happens. The output from Valgrind is bellow.

What version of the product are you using? On what operating system? latest revision (441) at Google svn repository running on Linux/gcc-4.4.3/gfortran-4.4.3

Please provide any additional information below. I suppose it appears when there is a failure in LAPACK. This is what LOBPCG prints: >Error in LOBPCG: >Orthonormalization of residuals failed >DPOTRF INFO = 9

And what Valgrind means about the memory leak - this is the trace, last calls are ordered first:

==666== 752 (160 direct, 592 indirect) bytes in 8 blocks are definitely lost in loss record 5 of 5 ==666== at 0x4024F20: malloc (vg_replace_malloc.c:236) ==666== by 0x838726E: utilities_FortranMatrixCreate (fortran_matrix.c:79) ==666== by 0x83847B0: lobpcg_solve (lobpcg.c:657) ==666== by 0x8384478: lobpcg_solve_double (lobpcg.c:388) ==666== by 0x816C6CA: lobpcg_driver_ (lobpcg_driver.c:253) ==666== by 0x8101475: __module_adaptivity_MOD_adaptivity_solve_eigenvectors (module_adaptivity.f90:2054)

It seems to me that a utilities_FortranMatrix* pointer is not deallocated in case of a failure of LAPACK DPORTF function.

I would be grateful if you could reassure that all memory is properly deallocated in case of failure of orthonormalization process. Thanks.

Comment #1

Posted on Aug 25, 2011 by Grumpy Camel

Thanks very much for your comment!

This is fixed today in the source tree. An update in PETSc/SLEPc will follow.

Status: Fixed

Labels:
Type-Defect Priority-Medium