[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
memory leak in DLD using FFTW3
From: |
Eric Chassande-Mottin |
Subject: |
memory leak in DLD using FFTW3 |
Date: |
Thu, 31 Jul 2003 18:05:50 +0200 (CEST) |
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
- memory leak in DLD using FFTW3,
Eric Chassande-Mottin <=