Thread segmentation fault using FFTW - c

Question

we have a C software on a i.MX53 (SO based on Linux) that have to compute a FFT; for this purpose we have adopted the FFTW library. For performances reasons we have decided to separate the FFT from the main application, using a separated thread. The overall application seems work, but after a while we have a segmentation fault in correspondence of fftwf_execute. I am sure of this because without this single istruction we have not segmentation faults. We have made several attempts but the problem persists. Here parte of the thread function:
void* vGestDiag_ThreadFFT( void* unused )
{
Int32U idx = 0, idxI = 0, idxJ = 0, idxZ = 0, idxK = 0;
Flo32 lfBufferAccm_chn01[LEN_BUFFER_SAMPLES];
Flo32 lfBufferAccm_chn02[LEN_BUFFER_SAMPLES];
Flo64 dblBufferFFT[LEN_BUFFER_SAMPLES];
Int32U ulCntUtilSample = 0;
float *in;
fftwf_complex *out;
fftwf_plan plan;
/* other variables.... */
/* Init */
memset(lfBufferAccm_chn01, 0x00, LEN_BUFFER_SAMPLES*sizeof(Flo32));
memset(lfBufferAccm_chn02, 0x00, LEN_BUFFER_SAMPLES*sizeof(Flo32));
memset(dblBufferFFT, 0x00, LEN_BUFFER_SAMPLES*sizeof(Flo64));
/* other local memsets .... */
/* Inputs */
pthread_mutex_lock(&lockIN);
ulCntUtilSample = wulCntUtilSample;
/* other inputs.... */
for (idxJ = 0; idxJ < ulCntUtilSample; idxJ++)
{
boBuffCirc_ReadBuffer(&wulBufferAcc01, &ulTmpValue);
lfBufferAccm_chn01[idxJ] = (Flo32)((((Flo32)ulTmpValue - ACC_Q)/ACC_M) * ACC_U) * wlfSensAcc;
boBuffCirc_ReadBuffer(&wulBufferAcc02, &ulTmpValue);
lfBufferAccm_chn02[idxJ] = (Flo32)((((Flo32)ulTmpValue - ACC_Q)/ACC_M) * ACC_U) * wlfSensAcc;
}
pthread_mutex_unlock(&lockIN);
/* --------- Plan FFT ------------------------- */
in = (float*) fftwf_malloc(sizeof(float) * ulCntUtilSample);
out = (fftwf_complex*) fftwf_malloc(sizeof(fftwf_complex) * ulCntUtilSample);
fftwf_plan_with_nthreads(1);
plan = fftwf_plan_dft_r2c_1d(ulCntUtilSample, in, out, FFTW_ESTIMATE);
for (idxI = 0; idxI <= 1; idxI++)
{
switch(idxI)
{
case 0:
memcpy(in, lfBufferAccm_chn01, ulCntUtilSample*sizeof(float));
break;
case 1:
memcpy(in, lfBufferAccm_chn02, ulCntUtilSample*sizeof(float));
break;
default:
break;
}
/* --------- FFT ------------------------- */
/* EXEC */
fftwf_execute(plan);
/* Complex -> Real */
for (idxZ = 0; idxZ < ulCntUtilSample; idxZ++)
{
dblBufferFFT[idxZ] = cabs(out[idxZ]);
}
/* --------- End FFT ------------------------- */
/* Post-Processing FFT */
/* post-processing and outputs in module static variables, within mutex */
}
/* DEL plan */
fftwf_destroy_plan(plan);
fftwf_free(in);
fftwf_free(out);
/* exit */
pthread_exit(NULL);
}
Variables starting with 'w' are module static variables, LEN_BUFFER is oversized respect the number of samples.
Thanks everyone for helping!!

Answer 1

This is my first project involving threads and also my coworkers have not a great experience, so we have not considered several issues. The first one was the difference between DETACHABLE and JOINABLE: our application have not to wait for thread completing; indeed this was the problem that lead us to thread (the main that waited a long time for FFT completing, while this was not necessary). The previous version of my SW was default, joinable, so resources allocated to the thread were never free. The second point that we have not considered was that generating a thread requires additional resources. In the previous version of my SW was generated a thread each time that FFT had to be computed; in our application this append about every 10 second or more, so apparently not critical; moreover the fastest is FFT beginning, the less data are used for FFT (is a long story, but we can summerized so); finally, the use of mutex and the logic of the algorithm apparently protected the shared resources (it was quite improbable that a shared resources was used from the threads and main at the same time). Unfortunately, the thread generation, after several cycles saturated the memory (we are working not on a PC but on a simple microprocessor....), and this was the origin of the segmentation faults, so i believe.
I have solved the problem in this way: the FFT thread is generated at the start of the application, so it is generated only a single thread, together with the main. Within the thread is an infinite loop that periodically (at the moment 4 times fastest than the main loop) check for a shared variable that indicate the request for FFT: if true, the thread read and copy locally a shared memory that cointains the FFT inputs and other required parameters. At the end of the processing, outputs are saved in a shared memory and another flag is set to indicated the main loop that a fft is available. Each shared data is accessed R/W using mutex, both within thread and main, and only data used by the thread are controlled by mutexes. The thread is generated as detachable without any kills or exits, because the thread has to live "forever" together with the main. Yesterday this SW has run for several hours without problems (i have stopped manually) and also in stress conditions.