Possible memory leak in fmpz_bin_uiui

[Kiran Kedlaya]

Long-time user, first-time poster.

I just ran valgrind on some FLINT-based C code and it seems to suggest a memory leak in fmpz_bin_uiui (binomial coefficients); see below for the relevant portion of the report. Rewriting to compute the binomial coefficients by hand makes the leak indication go away, suggesting an issue at the level of FLINT or lower; the FLINT code looks like a pretty thin boilerplate wrapper around a GMP function. Thoughts?

Kiran

==88545== 32,768 bytes in 1 blocks are still reachable in loss record 1 of 3
==88545==    at 0x553BE1F: realloc (vg_replace_malloc.c:1801)
==88545==    by 0x409DCE2: flint_realloc (memory_manager.c:106)
==88545==    by 0x41E67D2: _fmpz_new_mpz (fmpz.c:133)
==88545==    by 0x41E6B5D: _fmpz_promote (fmpz.c:228)
==88545==    by 0x41E6B5D: _fmpz_promote (fmpz.c:224)
==88545==    by 0x41DCF49: fmpz_bin_uiui (bin_uiui.c:18)
==88545==    by 0x4055A20: ps_static_init (power_sums.c:285)
==88545==    by 0x403441F: wp_rust::main (main.rs:61)

[Edgar Costa]

Are you calling flint_cleanup() at the end of your program?

I think the "still reachable" category is FLINT's internal mpz cache pool, not a real leak.
FLINT allocates mpz_t structs in bulk for performance and reuses them rather than freeing them immediately. 

--

---
You received this message because you are subscribed to the Google Groups "flint-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flint-devel...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/flint-devel/e48f5681-a331-4533-8671-b5fbbb8f19fcn%40googlegroups.com.

[Albin Ahlbäck]

Hi Kiran,

Have you looked at

https://flintlib.org/doc/memory.html#global-caches-and-cleanup

In particular, flint_cleanup_master() should be called before exiting a program.  Is the memory leak still occurring after this has been called?

Best,

Albin

--

[Kiran Kedlaya]

That does resolve the issue, yes. There were other issues raised by valgrind but those were because the code is multithreaded, and I was failing to call flint_cleanup() at the end of each thread's lifespan. Doing that also makes valgrind happy!

Thanks,

Kiran