Home My Page Projects PaStiX
Summary Activity Forums Lists Docs News Files

Forum: open-discussion

Monitor Forum | Start New Thread Start New Thread
RE: Memory leak in csc_checksym (csc_utils.c) [ Reply ]
By: Francois PELLEGRINI on 2013-01-11 19:55
[forum:110338]
As far as Scotch is concerned, this leak is not our fault ! ;-)
This buffer is allocated by Lex and Yacc to run the parsers, and is not de-allocated afterward. Since it is allocated only once, and is still reachable, it is not a leak so to speak. However, I have no direct way to reclaim it.
Regards,
f.p.

RE: Memory leak in csc_checksym (csc_utils.c) [ Reply ]
By: Xavier Lacoste on 2013-01-11 13:39
[forum:110337]
Thanks for the report, you are right the free is missing.
I'll apply your fix !

RE: Memory leak in csc_checksym (csc_utils.c) [ Reply ]
By: Frank Everdij on 2013-01-11 10:57
[forum:110336]
Apologies, it seems i have made an error posting it as user 'Nobody'. It's me, user 'feverdij'

Frank

Memory leak in csc_checksym (csc_utils.c) [ Reply ]
By: Nobody on 2013-01-11 10:48
[forum:110335]
While testing a program for non-linear finite element calculation in which i repeatedly need to solve an unsymmetrical stiffness matrix of about 1.2 million degrees of freedom, i noticed a rapid cumulative growth in memory usage.
After running 'simple' in the examples/bin directory on an unsymmetrical matrix from the University of Florida Sparse Matrix Collection (i used http://www.cise.ufl.edu/research/sparse/matrices/Bai/bfwa62.html) i found the problem when using pastix_checkMatrix to symmetrize the sparse matrix graph:

frank@link:~/projects/pastix_release_3984/src/example/bin$ valgrind --leak-check=full ./simple -mm bfwa62.mtx
==26392== Memcheck, a memory error detector
.
[snip]
.
Check : Numbering OK
Check : Sort CSC OK
Check : Duplicates OK
Check : Graph symmetry OK
Add 12 null terms
.
[snip]
.
Precision : ||ax -b||/||b|| = 7.3920226875043224341e-16
==26392==
==26392== HEAP SUMMARY:
==26392== in use at exit: 17,274 bytes in 5 blocks
==26392== total heap usage: 485 allocs, 480 frees, 4,392,940 bytes allocated
==26392==
==26392== 248 bytes in 1 blocks are definitely lost in loss record 3 of 5
==26392== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26392== by 0x4628C0: csc_checksym (csc_utils.c:563)
==26392== by 0x435D4C: pastix_checkMatrix_int (pastix.c:5878)
==26392== by 0x436CC3: pastix_checkMatrix (pastix.c:6367)
==26392== by 0x403B23: main (simple.c:170)
==26392==
==26392== LEAK SUMMARY:
==26392== definitely lost: 248 bytes in 1 blocks
==26392== indirectly lost: 0 bytes in 0 blocks
==26392== possibly lost: 0 bytes in 0 blocks
==26392== still reachable: 17,026 bytes in 4 blocks
==26392== suppressed: 0 bytes in 0 blocks
==26392== Reachable blocks (those to which a pointer was found) are not shown.
==26392== To see them, rerun with: --leak-check=full --show-reachable=yes
==26392==
==26392== For counts of detected and suppressed errors, rerun with: -v
==26392== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)

After a bit of analysis it appears that the problem lies in not freeing the internal 'toadd' array, allocated in csc_utils.c:563. This array is used to add zeroes to an unsymmetric sparse array structure to symmetrize its graph, thereby leaking memory on every call to pastix_checkMatrix().
I fixed this by adding:

memFree_null(toadd);

between line 660 and 661. I'm not sure if that is the correct place btw.

There also is a fixable leak in a Scotch 5.1 parser string, which accounts for the 'still reachable' blocks not freed yet, but since this leak is relatively minor and only pertaining to Scotch 5.1, i haven't investigated this further.

Let me know if this helpful in any way,

Frank