Printable View
I'm getting a stack overflow error because for large numbers, this code I'm working on allocates too much on the stack.
Is there a way of tracking stack allocations specifically?
Will multithreading solve my problem if each thread is doing the static allocations?
Would I really have to use malloc or new every time I wanted to use memory just to make my code scale to huge numbers?
In C++, we usually use new instead of malloc. I would suggest you using a debugger.
use std::vectors instead of C arrays allocated on stack
What is your compiler again? You can set what the stack size is and avoid trying to allocate too much.
So here's the thing, I'm using nothing but vectors. And you're right, I should maybe use std::array instead of C-style ones. Well, I really mean that I'm using a lot of vectors and a lot of what I'm already doing is being manually allocated by new() and in one instance to comply with the ISO C standard, malloc() and that's because of a weird constructor glitch. Basically, malloc and free makes valgrind happy but new and delete make it freak out.
I get that if I don't use
then the vector itself is a static allocation. The element in it are heap allocations but the vector itself would all be on the stack, right?Code:std::vector<int> *vec = new std::vector<int>(size);
I'm using a lot of recursion though too. That might having something to do with it.
My compiler is also gcc 4.8.1.
Why are you using new for that snippet? You probably should be just using a "standard" instance and use the constructor to set the size.
Code:#include <iostream>
#include <vector>
int main()
{
int vec_size = 100;
std::vector<int> vec(vec_size);
std::cout << vec.size() << std::endl;
return 0;
}
Most likely. If you run the program with your debugger, the debugger should tell you exactly where it detects the problem and then you can look at the variables at the time of the crash to help determine the actual problemQuote:
I'm using a lot of recursion though too. That might having something to do with it.
If you need more help you'll need to show much more code, the snippet you've shown is nowhere near enough code to help determine your problems.
Jim
Okay, so here's the thing, my code is actually more of project and it is quite long so posting it might not be an option.
Would this be the time to learn gdb?
It's always a good time to learn gdb. If you're on Unix, Linux or OSX also look into valgrind.Quote:
Originally Posted by MutantJohn
Easiest way to detect stack overflow?
Run the program under a debugger. Let program crash.
Debugger stops. Open stack backtrace. There. You've identified basically what function(s) caused the overflow because 99% of the time, it's recursion.
You can then go back and look at variable values to see what caused it to enter this "infinite" recursion.
As for multi-threaded, don't go there. It's difficult to solve such problems even with a debugger, let alone without.
Stop using new and malloc unless you really have to (where and why do you use them?). Especially malloc (why are you using it?).
malloc and new aren't going to cause stack overflow. Assuming gcc implements vectors similar to microsoft, only a small header structure is used for a vector, and the data for the vector is allocated / reallocated / freed from the heap. If you use a pointer to a vector and new, then only the pointer is on the stack.
To help with a stack overflow issue, you could add a global static variable for each recursive function. Each global variable would be incremented before each recursive call and decremented just after each return, then use cout to display function name and recursion level. If the amount of output is slowing things down too much, redirect the output to a text file. Chances are that some recursive process is nesting too many times including one where the condition to stop recursion is never met.
As mentioned, using a source level debugger would make this much easier. If you're running on windows, microsoft visual c++ express is free and has a good source level debugger as part of it's main IDE.
Well if you can't post the code, then please at least tell us what the code is doing.
I.e. at a high level what operation is it performing that causes stack overflow.
E.g. Is it trying to solve a Sudoku? Is it trying to find the shortest path from A to Z? Is it performing a sort of some data?
Of course the chances that any of the above are a "yes" is very small, but the questions themselves give you an idea of what you need to tell us.
Presumably it's his "Delaunay triangulation" code that he posted in another thread.Quote:
Originally Posted by iMalc