id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
3548	Bad memory leak with umfpack	crupp@…	Willi Braun	"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
"	defect	closed	high	1.11.0	Run-time		fixed