Here is a warning from Valgrind, followed by a succession of invalid write and read errors:
Warning: client switching stacks? SP change: 0xffefffc00 --> 0xffecf7e20 <...> Invalid write of size 8 <...> Invalid read of size 8 <...>
Issues reported by Valgrind must be solved in order: the succession of invalid writes and reads is consequence of the initial warning. From Valgrind manual description (see the section about warning messages), this might indicate a too large array allocated on the stack (Valgrind assumes that the client is switching to a different stack because of a large change in the stack pointer).
The backtrace of invalid writes and reads may look like:
at 0x10DD32: cosmox::PerturbsCosmoclass::interpolate() (perturbations.cc:79) by 0x10DAF4: cosmox::PerturbsCosmoclass::PerturbsCosmoclass(int, char**) (perturbations.cc:62) <...>
It is convenient to read each backtrace bottom-up to identify the origin of the problem. Let's inspect the issue with GDB. In the example below a break point is set within the function interpolate() (at the top of the backtrace shown above), where a potentially large array source_kt is allocated on the stack.
Thread 1 "cosmox" hit Breakpoint 1, cosmox::PerturbsCosmoclass::interpolate (this=0x55555584a890) at perturbations.cc:79 79 for (auto it : index_tp) (gdb) p source_kt value requires 3177944 bytes, which is more than max-value-size (gdb) show max-value-size Maximum value size is 65536 bytes.
This confirms the suspected stack overflow: the array source_kt is too large. A simple solution is to move the array from the stack to the heap. For instance, instead of declaring it on the stack as:
double source_kt[kt_size]; // kt_size is a large int.
allocate it on the heap as (assume C++, in C consider using malloc/free instead):
double* source_kt = new double[kt_size];
<...>
delete[] source_kt;
Note that this requires to eventually free the memory with delete[]. Depending on the specific problem, a better solution may be to use a smart pointer or a vector.