memory leak in the FFT operators ?

[arwina]

I m trying to debug my purify code for w-projection using valgrind and I noticed that it complains about memory leaks in the FFT operators. Here is an example of what I get:

==77939== 24 bytes in 1 blocks are still reachable in loss record 56 of 531 ==77939== at 0x4C2D110: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==77939== by 0x55A44E4: fftw_malloc_plain (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.3.2) ==77939== by 0x56755EE: fftw_mkapiplan (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.3.2) ==77939== by 0x56795F9: fftw_plan_many_dft (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.3.2) ==77939== by 0x5678A68: fftw_plan_dft (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.3.2) ==77939== by 0x5678837: fftw_plan_dft_2d (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.3.2) ==77939== by 0x7BE515: Eigen::internal::fftwplan::inv2(double () [2], double (_) [2], int, int) (ei_fftw_impl.h:130) ==77939== by 0x7BF551: Eigen::internal::fftwimpl::inv2(std::complex, std::complex const_, int, int) (ei_fftw_impl.h:227) ==77939== by 0x7BE33A: purify::FFTOperator::inverse(Eigen::Matrixstd::complex<double, -1, -1, 0, -1, -1> const&) (FFTOperator.cc:162)

==77939== by 0x70684B: main (w_correction_padmm_reconstruction_diff_GS_all.cc:181)

Any ideas if it is a genuine leak ?

[adrianjhpc]

Where is the code (which branch) and I'll have a look and check.

On 10/06/2016 13:05, Arwa Dabbech wrote:

I m trying to debug my purify code for w-projection using valgrind
and I noticed that it complains about memory leaks in the FFT
operators. Here is an example of what I get:

==77939== 24 bytes in 1 blocks are still reachable in loss record 56 of 531 ==77939== at 0x4C2D110: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==77939== by 0x55A44E4: fftw_malloc_plain (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.3.2) ==77939== by 0x56755EE: fftw_mkapiplan (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.3.2) ==77939== by 0x56795F9: fftw_plan_many_dft (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.3.2) ==77939== by 0x5678A68: fftw_plan_dft (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.3.2) ==77939== by 0x5678837: fftw_plan_dft_2d (in /usr/lib/x86_64-linux-gnu/libfftw3.so.3.3.2) ==77939== by 0x7BE515: Eigen::internal::fftw_plan::inv2(double (/) [2], double (/) [2], int, int) (ei_fftw_impl.h:130) ==77939== by 0x7BF551: Eigen::internal::fftw_impl::inv2(std::complex/, std::complex const/, int, int) (ei_fftw_impl.h:227) ==77939== by 0x7BE33A: purify::FFTOperator::inverse(Eigen::Matrixstd::complex<double, -1, -1, 0, -1, -1> const&) (FFTOperator.cc:162)

==77939== by 0x70684B: main
(w_correction_padmm_reconstruction_diff_GS_all.cc:181)

Any ideas if it genuine leak ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/astro-informatics/purify/issues/42, or mute the thread https://github.com/notifications/unsubscribe/AREsM6v7KW6gVMpa_E-DjuJtON-uh0c1ks5qKVMZgaJpZM4Iy431.

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

[Luke-Pratley]

If I remember correctly, the FFT operator code can be found here https://github.com/astro-informatics/purify/blob/cpp-w-projection/cpp/FFTOperator.h . However, it is interfaced with Eigen, which calls FFTW #include <unsupported/Eigen/src/FFT/ei_fftw_impl.h>

If this is a memory leak, it might be worth also fixing on the cpp-gridding-refactor branch

[arwina]

The branch is cpp-wprojection-omp, I m running the script run_diff_energy_gsparse_valgrind.sh to test memory leaks of the example w_correction_padmm_reconstruction_diff_GS_all.cc