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() (
by 0x10DAF4: cosmox::PerturbsCosmoclass::PerturbsCosmoclass(int, char**) (

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
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.