Bad memory leak with umfpack

[crupp@…]

When solving with -ls=umfpack, a memory leak quickly grows as the model solves. On large models the computer eventually runs out of memory. As an example, using valgrind on the DoublePendulum model gives the following results:

With default solver:
==1580== LEAK SUMMARY:
==1580== definitely lost: 26,150 bytes in 1,120 blocks
==1580== indirectly lost: 4,907,693 bytes in 124,203 blocks
==1580== possibly lost: 2,432 bytes in 4 blocks
==1580== still reachable: 22,220 bytes in 24 blocks
==1580== suppressed: 0 bytes in 0 blocks

With umfpack:
==1572== LEAK SUMMARY:
==1572== definitely lost: 738,838 bytes in 3,402 blocks
==1572== indirectly lost: 5,304,359 bytes in 149,197 blocks
==1572== possibly lost: 7,958 bytes in 146 blocks
==1572== still reachable: 22,220 bytes in 24 blocks
==1572== suppressed: 0 bytes in 0 blocks

With umfpack and stopTime=20 (default is 3):
==1894== LEAK SUMMARY:
==1894== definitely lost: 4,700,758 bytes in 16,102 blocks
==1894== indirectly lost: 7,540,464 bytes in 288,885 blocks
==1894== possibly lost: 8,446 bytes in 158 blocks
==1894== still reachable: 22,220 bytes in 24 blocks
==1894== suppressed: 0 bytes in 0 blocks

[crupp@…]

One more data point:

With default solver and stopTime=20:
==2332== LEAK SUMMARY:
==2332== definitely lost: 26,294 bytes in 1,122 blocks
==2332== indirectly lost: 4,908,950 bytes in 124,213 blocks
==2332== possibly lost: 2,432 bytes in 4 blocks
==2332== still reachable: 22,220 bytes in 24 blocks
==2332== suppressed: 0 bytes in 0 blocks

[Willi Braun]

This memory leak is caused by umfpack it self, so I can't fix it here. Also we are using a quite old version of umfpack due to a license change.

[crupp@…]

Sorry to reopen this, but I disagree that the leak is caused by umfpack.

I looked into this further and it looks like umfpack_di_numeric does not check to see if the *Numeric variable is already allocated, so it always allocates a new *Numeric object regardless of what is passed in. It seems strange to me that umfpack wouldn't reuse the memory for a matrix with the same *Symbolic structure, but I'm not familiar with this algorithm so perhaps there is a reason. I also couldn't find a code example of the proper way to do this repeated factorization and the documentation is not clear (it only says it can be done).

The solution seems to be to call umfpack_di_free_numeric before each umfpack_di_numeric call. I tested this and it fixes the leak. I will attach a patch with the fix.

The patch also makes a change to utilize the umfpack_di_wsolve function with a preallocated workspace. This should speed up computation a bit by removing unnecessary allocations.

[crupp@…]

This was fixed in PR661.