memory leak in DLD using FFTW3

[Eric Chassande-Mottin]

hi octavers,

let me give some updates about the memory leak I found
when calling many times the FFTW version 3.0 from an
Octave's DLD function.

see here for the background :
http://www.octave.org/mailing-lists/help-octave/2003/1211

I have passed octave2.1 into valgrind (thanks to David Bateman) while
running my function. the conclusion of this test (see below for details)
is that the function fftw_plan_many_dft_r2c seems to be the source of the
leak (~40 bytes per call).

I contacted the FFTW group (thanks to Matteo Frigo). 
we recoded the DLD test function (code available here: 
http://www.octave.org/mailing-lists/help-octave/2003/1211)
in a simple stand alone C++ code (this code is attached to this message).
result: the leak disappears in the stand alone code!
(valgrind answers OK and the code runs in constant memory).

something happens at the interface between Octave and the FFTW?

perhaps a good idea is to compile the DLD as a standalone against
liboctave? (it is not clear to me how to do that).

the memory management tools of FFTW that one use enabling configure 
--enable-debug
and calling fftw_malloc_print_minfo() at the end of the program
does not seems to be compatible with octave2.1

another fact is that the memory leak is apparently not reproducible
on a redhat 7.3. (I have a Debian 3.0).

if you have also a Debian 3.0, please try the test explain here:
http://www.octave.org/mailing-lists/help-octave/2003/1211
I'd be curious.

any hint?
éric.

PS: report on memory leaks
    ----------------------

> octave has memory leaks but they remain small (see line regarding leaks
> that are "definitely lost") and they do not depend upon the test code I
> run.  note also that the most part of the leak (395471) in the valgrind
> report below seems to come from the call to fftw_plan_many_dft_r2c
> (391504).
> 
> ==30539== 391504 bytes in 19624 blocks are definitely lost in loss record 113 
> of 114
> ==30539==    at 0x401678B8: malloc (vg_clientfuncs.c:103)
> ==30539==    by 0x439268FD: fftw_malloc_plain (in /my_path/fft_test.oct)
> ==30539==    by 0x439343F8: fftw_plan_many_dft_r2c (in /my_path/fft_test.oct)
> ==30539== 
> ==30539== LEAK SUMMARY:
> ==30539==    definitely lost: 395471 bytes in 19941 blocks.
> ==30539==    possibly lost:   486604 bytes in 526 blocks.
> ==30539==    still reachable: 20510944 bytes in 185104 blocks.
> ==30539==         suppressed: 0 bytes in 0 blocks.
> 
> and this number scales with the number N of iterations but it is
> independent from the size of the data S using the following code:
> 
> N=10000;S=1024;x=zeros(S,1);for icol=1:N,dummy=fft_test(x);end;
> 
> (the report above is for N=10000) here is the report for N=1000
> 
> ==31873== 39420 bytes in 1973 blocks are definitely lost in loss record 106 
> of 114
> ==31873==    at 0x401678B8: malloc (vg_clientfuncs.c:103)
> ==31873==    by 0x439268FD: fftw_malloc_plain (in /my_path/fft_test.oct)
> ==31873==    by 0x439343F8: fftw_plan_many_dft_r2c (in /my_path/fft_test.oct)
> ==31873== 
> ==31873== LEAK SUMMARY:
> ==31873==    definitely lost: 43387 bytes in 2290 blocks.
> 
> making several trials, one get the dependency:
> 
>  iterations     N<32   N=32    N=40  N=50 N=100 N=1000 N=10000  N=20000
>  leak size     no leak 1.3kB  1.6kB   2kB  4kB   ~40kB  ~400kB  ~785kB
> 
> (here we measure only the leak related to fftw_plan_many_dft_r2c)
> 
> this is why I suspect the problem is more likely to come from FFTW
> rather than octave.

fft_test_standalone.cc
Description: fft_test stand alone