Why do I get segmentation fault error?

[JamieAl]

I am usually pretty good at catching the root of segmentation fault error except this time. I have tested the code several times at different lengths with no success unfortunately. It seems like the issue stems from three different functions:
1. calc_diamag3D
2. r2c3D (only when used inside function 1 and not when used separately for some reason)
3. fourierDivision3D (same issue as function 2, works separately but not inside 1)

I am posting the full code on my GitHub since the error disappears when rewriting a simple example which tells me I am missing something. I think it maybe in the way I am initializing some variables when passing them or could be in the memcpy line in r2c3D function.

Note: I am aware of all the "free" lines I am missing at this sample code.

Code: https://github.com/JamieAlM/Eigen_Optimization/tree/main

[kbw]

I can't get it to compile, but then again, I can only install fftw v2, not v3.

The code is monolithic and is really C, not C++ ; so it uses none of the protections that C++ offer.

The best I can say is, run it in the debugger, let it crash, then work backwards to see what caused the crash a fix that, then repeat.

[EDIT]
For example, this prototype:

static const int ncomp = 2;

void CollFreqk_inertia3D(
  double nek[][ncomp],
  double Tik[][ncomp],
  double Tek[][ncomp],
  double kb,
  double eps0,
  double mi,
  double me,
  double ri,
  double rn,
  double nn,
  double Oci,
  double Oce,
  double e,
  double nuink[][ncomp],
  double nuiek[][ncomp],
  double nuiik[][ncomp],
  double nuenk[][ncomp],
  double nueek[][ncomp],
  double nueik[][ncomp],
  double isigPk[][ncomp],
  double invnk[][ncomp],
  double hallIk[][ncomp],
  double hallEk[][ncomp]);

How much thought went into this?

If you're writing from scratch, why not look for a C++ wrapper like: https://fftwpp.sourceforge.net/

[Peter87]

Have you tried using Valgrind or an UB/address sanitizer?

In my experience that is usually better than using a normal debugger because the root cause of the problem might not cause a crash until later in possibly unrelated parts of the code. Valgrind instead often points me closer to the real cause of the problem. Sanitizers should be able to do the same.

[coder777]

The index calculation looks wrong. I suggest to assert() the resulting index:

E.g.

const int size = nx*ny*nz;
const int idx = k + nz * (j + ny * i);
assert((idx >= 0) && (idx < size));

[JamieAl]

Thanks all for the suggestions and feedback!

I was able to run Valgrind with this and here is what I got:

Invalid read of size 8
==253==    at 0x485294F: memmove (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==253==    by 0x10D011: memcpy (string_fortified.h:29)
==253==    by 0x10D011: r2c3D (MemoryLeakTest.cpp:1132)
==253==    by 0x10D011: fourierDivision3D(double (*) [2], double (*) [2], double (*) [2]) (MemoryLeakTest.cpp:1204)
==253==    by 0x10D264: calc_diamag3D(double (*) [2], double (*) [2], double (*) [2], double*, double, double, double (*) [2], double (*) [2], double (*) [2], double (*) [2]) (MemoryLeakTest.cpp:1089)
==253==    by 0x10AAED: main (MemoryLeakTest.cpp:694)

which as I suspected points to the three functions I mentioned above in particular r2c3D at memcpy line:

memcpy(input_array, rArr, (nx*ny*nz)*sizeof(fftw_complex));

[Peter87]

The problem seems to be that input_array contains elements of type fftw_complex while rArr contains elements of type double so you can probably not use memcpy to copy between them like you do.

[JamieAl]

@Peter87
You are right actually! Thanks!