Memory leak

[Martin Schreiber]

There seems to be a memory leak even after calling shtns_destroy.

Valgrind still detects some memory allocated by fftw which should have been released, see below.

I called

    shtns_destroy(shtns);
    fftw_cleanup();

at the end of the program which should have released everything.

A reproducer is attached (see README file)

Cheers,

Martin

…

==61224==
==61224== 44,384 bytes in 1 blocks are still reachable in loss record 109 of 109
==61224== at 0x48490B0: memalign (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==61224== by 0x48A73D8: fftw_malloc_plain (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.6.10)
==61224== by 0x48A8CF6: ??? (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.6.10)
==61224== by 0x48ABCEF: fftw_solvtab_exec (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.6.10)
==61224== by 0x48F0554: fftw_rdft_conf_standard (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.6.10)
==61224== by 0x499A8E4: fftw_configure_planner (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.6.10)
==61224== by 0x49A21C7: fftw_the_planner (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.6.10)
==61224== by 0x499A3D1: fftw_mkapiplan (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.6.10)
==61224== by 0x49A1D25: fftw_plan_many_dft (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.6.10)
==61224== by 0x1238A3: planFFT (in /home/martin/Downloads/shtns-3.5.4/shtns/memleak_reproducer/SHT_example)
==61224== by 0x12745B: shtns_set_grid_auto (in /home/martin/Downloads/shtns-3.5.4/shtns/memleak_reproducer/SHT_example)
==61224== by 0x12773C: shtns_set_grid (in /home/martin/Downloads/shtns-3.5.4/shtns/memleak_reproducer/SHT_example)
==61224==

…

‌

‌

[Nathanaël Schaeffer]

I just ran your reproducer. It tells me: “All heap blocks were freed -- no leaks are possible”.
It looks like an fftw issue to me. What fftw version are you using? I’m using 3.3.8.

‌

[Martin Schreiber]

I just tested it with fftw3.3.10 as well as fftw3.3.8 and also with the most recent shtns version from the repository. I also updated valgrind to the most recent version 3.21.0. Same problem.

I had a look into sht_init.c and there seems to be no fftw_destroy_plan(…) called in shtns_destroy(…).

Once I added

    fftw_destroy_plan(shtns->fftc);
    fftw_destroy_plan(shtns->fft_cplx);

at the end, this solved this issue and no memory leaks occurred anymore (this code obviously only holds for this special memleak reproducer).

The website https://www.fftw.org/fftw3_doc/Using-Plans.html states that “fftw_cleanup does not deallocate your plans, however. To prevent memory leaks, you must still call fftw_destroy_plan before executing fftw_cleanup.”. It seems that the destroying of plans is entirely missing in shtns?

[Nathanaël Schaeffer]

Oh yes, my bad: I was running your reproducer in the cuda-rtc branch, in which this has been fixed a while ago by commit 0af3140b.
As this is not a major bug, I’m not sure the backport to master is required, since the cuda-rtc should pretty soon become the main branch with a new version bump.

[Martin Schreiber]

Sounds good to me to wait for the next release.

Thanks for all your work on this!

‌