Segmentation fault using FFTW

Question

Segmentation fault using FFTW

I have a pretty involving program that uses an in house FFT algorithm. I recently decided to try using FFTW for a performance increase. Just as a simple test to ensure that FFTW would link and run, I added the following code to the beginning of the application, however, when I run, I get a segmentation fault when I create the fftwf_plan:

const size_t size = 1024;
vector<complex<float> > data(size);
for(size_t i = 0; i < size; ++i) data[i] = complex<float>(i, -i);

fftwf_plan plan =
    fftwf_plan_dft_1d(size,
                      (fftwf_complex*)&data[0],
                      (fftwf_complex*)&data[0],
                      FFTW_FORWARD,
                      FFTW_ESTIMATE);
// ^ seg faults here ^

fftwf_execute(plan);
fftwf_destroy_plan(plan);

Any ideas what would be causing this?

Using FFTW 3.3. Tried 2 different compilers, g++ 4.1.1 and icc 11.1. Also, the core file file shows nothing of significance:

Thread 1.1: Error at 0x00000000
Stack Trace: PC: 000000, FP=Hex Address

EDIT

I reconfigured FFTW to add debug, using the following commands:

setenv CFLAGS "-fPIC -g -O0"
configure --enabled-shared --enable-float --enable-debug
make
make install

When the program has a segmentation fault, it is in a random location in the fftwf_plan_dft_1d() method, however, the stack trace allways shows that is in or below the function search which is called by mkplan.

c++

fftw

asked on Stack Overflow Sep 27, 2011 by

steveo225 • edited Sep 28, 2011 by

steveo225

3 Answers

Aparently the issue stems from multi-threading. Even though the main functions are thread safe in FFTW (e.g. fftwf_execute), the functions to create a plan are not. This doesn't fully explain why just running a test on startup failed, however, when I excapsulated the plan creation in mutex locks, the segmentation faults ceased.

answered on Stack Overflow Oct 3, 2011 by

steveo225

I'm 3 years late, but I've just stumbled upon a very similar problem, also when using multi-threading (--enable-openmp and fftw_plan_with_nthreads(omp_get_max_threads())). Mine seg faulted on fftw_destroy_plan(p).

It turned out that I didn't pay attention when restructuring my code, and I was calling fftw_cleanup_threads() before calling fftw_destroy_plan(p) ... silly, I know, but it got me chasing my tail for about 1h.

When using multi-threading, fftw_cleanup_threads() needs to be called after all fftw* functions, just as fftw_init_threads() needs to be called before any fftw* function.

answered on Stack Overflow Oct 20, 2014 by

Normadize

The creation and destruction of plans must be single threaded

fftw_init_threads();
#pragma omp parallel for
for(i=0;i<n;i++) {
   #pragma omp critical {
     plan = fftw_create_plan....
   }
   fftw_execute(plan); // or the fftw_execute_dft for multiple in/out fft operations
   #pragma omp critical {
     fftw_destroy_plan(plan);
   }
}
fftw_cleanup_threads();

answered on Stack Overflow Aug 1, 2018 by

Bob

User contributions licensed under CC BY-SA 3.0