[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
memory leak in DLD using FFTW3
From: 
John W. Eaton 
Subject: 
memory leak in DLD using FFTW3 
Date: 
Thu, 31 Jul 2003 13:06:07 0500 
On 31Jul2003, Eric ChassandeMottin <address@hidden> wrote:
 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/mailinglists/helpoctave/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).=20
 we recoded the DLD test function (code available here:=20
 http://www.octave.org/mailinglists/helpoctave/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).
When I try your code on my Debian system (up to date testing branch,
fftw3 3.0.12, g++ 3.3.1), I see
$ mkoctfile v fft_test.cc lfftw3
/usr/bin/g++ c fPIC I/usr/include/octave2.1.50
I/usr/include/octave2.1.50/octave mieeefp O2 fft_test.cc o fft_test.o
In file included from /usr/include/c++/3.3/backward/iostream.h:31,
from fft_test.cc:38:
/usr/include/c++/3.3/backward/backward_warning.h:32:2: warning: #warning This
file includes at least one deprecated or antiquated header. Please consider
using one of the 32 headers found in section 17.4.1.2 of the C++ standard.
Examples include substituting the <X> header for the <X.h> header for C++
includes, or <sstream> instead of the deprecated header <strstream.h>. To
disable this warning use Wnodeprecated.
/usr/bin/g++ shared o fft_test.oct fft_test.o lfftw3
devzero:444> octave
GNU Octave, version 2.1.50 (i386pclinuxgnu).
Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003 John W. Eaton.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or
FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'.
Please contribute if you find this software useful.
For more information, visit http://www.octave.org/helpwanted.html
Report bugs to <address@hidden>.
octave:1> page_screen_output=0;x=zeros(1024,1);for
icol=1:200000,icol,fft_test(x);end;
icol = 1
icol = 2
icol = 3
icol = 4
icol = 5
icol = 6
icol = 7
icol = 8
icol = 9
panic: Segmentation fault  stopping myself...
attempting to save variables to `octavecore'...
save to `octavecore' complete
Segmentation fault
or similar, but unfortunately not entirely reproducible (sometimes the
crash occurs at the first step, sometimes later, or not at all).
Running under gdb, I see
octave:1> page_screen_output=0;x=zeros(1024,1);for
icol=1:200000,icol,fft_test(x);end;
icol = 1
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x4100acc2 in fftw_codelet_t1fv_32 () from /usr/lib/libfftw3.so.3
If I allocate "in" with fftw_malloc and copy the data from x (see
below for modified function), it doesn't crash, but I do see the
leak. I don't see how this could be a bug in Octave though, because
if I comment out the section of code
fftw_plan planF = fftw_plan_dft_r2c_1d (N, in, out, FFTW_ESTIMATE);
if (planF == NULL) return retval;
fftw_plan planB = fftw_plan_dft_c2r_1d (N, out, in, FFTW_ESTIMATE); //
if (planB == NULL) return retval; //
fftw_execute(planF);
fftw_execute(planB); //
fftw_destroy_plan(planF);
fftw_destroy_plan(planB); //
the leak disappears. OTOH, I also don't see the leak when running
your standalone example.
 another fact is that the memory leak is apparently not reproducible
 on a redhat 7.3. (I have a Debian 3.0).
This would seem to point to some problem other than Octave or FFTW.
What compiler versions are on those systems?
 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.
Are you sure that these are really leaks? Is it possible that they
are due to initialization of objects that are not intended to be
deallocated (until Octave exits, and then perhaps not explicitly).
jwe
#include <octave/config.h>
#include <octave/parse.h>
#include <iostream.h>
#include <string.h>
#include <octave/defundld.h>
#include <octave/error.h>
#include <octave/octobj.h>
#include <octave/pager.h>
#include <octave/symtab.h>
#include <octave/variables.h>
#include <fftw3.h>
DEFUN_DLD (fft_test, args, ,
"test for a memory leak")
{
octave_value_list retval;
/* get input parameters */
int nargin = args.length ();
if (nargin < 1)
{
error("Usage: fft_test(x)");
return retval;
}
ColumnVector x(args(0).vector_value());
int N=x.length();
fftw_complex* out = (fftw_complex*) fftw_malloc(sizeof(fftw_complex) * N);
if (out == NULL) return retval;
double* in = (double*) fftw_malloc(sizeof(double) * N);
if (in == NULL) return retval;
for (int i = 0; i < N; i++)
in[i] = x(i);
fftw_plan planF = fftw_plan_dft_r2c_1d (N, in, out, FFTW_ESTIMATE);
if (planF == NULL) return retval;
fftw_plan planB = fftw_plan_dft_c2r_1d (N, out, in, FFTW_ESTIMATE); //
if (planB == NULL) return retval; //
fftw_execute(planF);
fftw_execute(planB); //
fftw_destroy_plan(planF);
fftw_destroy_plan(planB); //
fftw_cleanup();
for (int i = 0; i < N; i++)
x(i) = in[i];
retval(0)=x;
fftw_free(in);
fftw_free(out);
out=NULL;
return retval;
}

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.org
How to fund new projects: http://www.octave.org/funding.html
Subscription information: http://www.octave.org/archive.html
