Possible memory leak

[robol]

A memory leak has been reported at the end of the discussion in Issue #23. It seems less severe than the first one reported in that issues (which has been solved).

[rusins]

I believe I've found the leak (or maybe another).

In src/libmps/floating-point/mpc.c

function void mpc_mul has the line

s1 = init (mpf_get_prec (mpc_Re (rc)));

and the init function has the line

ptr = create_new_mps_tls (precision_needed);

and then the create_new_mps_tls function of course does

ptr = mps_new (mps_tls);

which is a call to mps_malloc that never gets freed.

At least that's what I gathered from Valgrind

==618677== 32 bytes in 1 blocks are still reachable in loss record 1 of 3
==618677==    at 0x483E77F: malloc (vg_replace_malloc.c:307)
==618677==    by 0x4C21179: mps_malloc (in /usr/lib/libmps.so.3.0.1)
==618677==    by 0x4C2E2FC: ??? (in /usr/lib/libmps.so.3.0.1)
==618677==    by 0x4C2EC44: mpc_mul (in /usr/lib/libmps.so.3.0.1)
==618677==    by 0x4C4CC1E: ??? (in /usr/lib/libmps.so.3.0.1)
==618677==    by 0x4C4CE6E: ??? (in /usr/lib/libmps.so.3.0.1)

[advanpix]

@rusin Looks like these allocations are properly freed in mps_mpc_cache_cleanup. Code is just a bit convoluted, init allocates in thread TLS memory. All per-thread allocations then freed with mps_mpc_cache_cleanup on thread exit.

[rusins]

@advanpix

Ah, I did not notice that. You are correct. The cleanup code now looks sound to me. Must be something else then...

[robol]

Thanks for the effort anyway! I did not have time to look into this further.