memory leak in DLD using FFTW3

[John W. Eaton]

On 31-Jul-2003, Eric Chassande-Mottin <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/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).=20
| we recoded the DLD test function (code available here:=20
| 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).

When I try your code on my Debian system (up to date testing branch,
fftw3 3.0.1-2, g++ 3.3.1), I see

$ mkoctfile -v fft_test.cc -lfftw3
/usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.50 
-I/usr/include/octave-2.1.50/octave -mieee-fp -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 -Wno-deprecated.
/usr/bin/g++ -shared -o fft_test.oct fft_test.o -lfftw3
devzero:444> octave
GNU Octave, version 2.1.50 (i386-pc-linux-gnu).
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/help-wanted.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 `octave-core'...
save to `octave-core' 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/defun-dld.h>
#include <octave/error.h>
#include <octave/oct-obj.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
-------------------------------------------------------------