Running out of stack memory according to valgrind?

[lo2]

Hi,

So I am currently writing a program, and I have encountered the following issue.
When I run my program with "valgrind --track-origins=yes" (after compiling with the -ggdb flag), I get this: "More than 10000000 total errors detected.", all these errors are "Invalid read of size 8" and "Invalid write of size 8", which I think is an error thrown when the program tries to read/write to memory that is not allocated.

So I have checked my program for any wrong allocations and I could not really find anything.

I then discovered the following message from valgrind:

Warning: client switching stacks? SP change: 0xffefcf760 --> 0xffed5a710
==184897== to suppress, use: --max-stackframe=2883600 or greater

So then I tried running "valgrind --max-stackframe=2883600 --track-origins=yes" and I do not get any errors. I then looked a bit around, and it seems the issue might be that valgrind thinks that I have run out of stack memory, and that this additional memory cannot be allocated, causing this error.

I cannot really figure out if this is a reasonable complaint my valgrind? I mean I am allocating some arrays dynamically, but not anything major, and I do not have any recursions. I am working on a Linux (Ubuntu) server with quite a lot of RAM.

How do I check if using too much stack memory?

[Ganado]

I mean I am allocating some arrays dynamically, but not anything major, and I do not have any recursions.

More importantly would be to tell us what arrays you aren't allocating dynamically. What are the sizes of your largest arrays that are being allocated statically (non-dynamically, i.e. on the stack)? Are you by chance using VLAs that have unknown compile-time size?

[Thomas1965]

Best would be if you show us the code.

[lo2]

Hi,

I am not allocating anything static. I do however allocate quite a lot of VLAs, is that what might cause the error? And what should I use instead?

I mean arrays are not as useful, if the length of them has to be known by compile time IMHO.

[Repeater]

A VLA is illegal C++. Your compiler should be stopping you.

You shouldn't be using them.

C++ has something for the case where the size isn't known at compile time; vector.

To summarise:
- VLAs are illegal in C++
- If you want a container like an array, that you can resize: std::vector

[lo2]

So if I have something like this:

int n = 10;
double x[n*n];

I should rather do something like this

std::vector<double> array(n*n);

And otherwise treat them the same? I guess I can also be sure that all the values of my vector are 0 at creation?

[Thomas1965]

Absolutely. If you change you mind later you can add or remove elements as well.

[lo2]

And that applies to arrays declared with new as well?

For example:

p = new double[4*l];

[Thomas1965]

No, arrays have fixed sizes. To add sth. to an array you have to create a new array with the new size, copy all elems from the old array and delete the old array.
The vector will do all that for you.

[Repeater]

You also should not be using new.

Whatever you're learning C++ from is teaching you significantly out of date C++ that is harder to write, harder to read, harder to debug and maintain... just bad news all round.

Don't use arrays. Use vector.

Don't use new/delete/malloc/free or anything involving manual memory management. Use RAII, and when you really must, smart pointers and make_unique / make_shared .

[lo2]

Thanks for all your answers, I will try and implement it!

Another question will it also make my code run faster using std::vector instead of VLAs?

[salem c]

> Another question will it also make my code run faster using std::vector instead of VLAs?
You need to make it work before you even begin to think about optimisations.

Further, you need to make sure you have a decent design and have chosen the appropriate algorithms and data structures for the task at hand.

For example, if you chose 'bubble sort', then it won't make a bean of difference whether you chose std::vector vs new vs malloc vs VLA.

You also need these things:
- functionally complete code.
- real world test data (not some half baked facsimile).
- a test suite to exercise the majority of the code (ideally automated so it's easy and repeatable).
- a profiling tool (to see where the real problems are, not just the ones you imagine).
- a source control system (so you have a baseline you can revert to if your tweaks fail).