2

I have some code here where there is an array of "Bacon" objects. I can compile and run it and add objects to the array, but when I make the array size more than one million, I run it and it says 'bacon.exe has stopped working' and I have to close it. I think it might be a memory leak, but I am still learning about that. I am using netbeans ide, and I tried allocating more memory when it gets compiled, but I couldn't figure out how to do that. Note: It isn't because my whole computer runs out of memory, because I still have 2GB free after running the program. Here is my code:

#include <iostream>
#include "Bacon.h"
using namespace std;

int main() {
    const int objs = 1000000;
    Bacon *bacs[objs];
    for(int i = 0;i < objs;i++){
        bacs[i] = new Bacon(2,3);
    }
        for(int i = 0;i < objs;i++){
        bacs[i]->print();
    }
    cin.ignore();
    return 0;
}
Boogley Beegly
  • 95
  • 1
  • 3
  • 11

4 Answers4

6

Your computer has plenty of memory, but only so much of it can be allocated on the stack. Try allocating it on the heap instead:

Bacon **bacs = new Bacon*[objs];

and later:

delete[] bacs;
nullptr
  • 2,244
  • 1
  • 15
  • 22
  • 1
    Alternative approach - use `std::vector`. This supports resizing at run-time which isn't really needed here, but it's idiomatic in C++ to prefer vectors to arrays anyway. More importantly, the vector is actually managing a heap-allocated array for you - it bypasses the stack size limit issue, but you don't have to worry about `new` and `delete`. The downside is that an array is sometimes more efficient, particularly an array in stack memory, but that's more an issue for low-level programmers who're developing library containers to worry about. –  May 04 '13 at 21:54
  • Another vote for `std::vector` over `new`. IMO, the only place for `new` is initializing a `unique_ptr` or `shared_ptr`! – japreiss May 05 '13 at 02:03
1

You're probably out of stack space.

You allocate huge array of pointers right on stack. Stack is limited resource (usually 8 megabytes per process). Size of pointer is usually 4 or 8 bytes; multiply it by one million and you overrun that limit.

  • Sorry I don't really know what that is. I am a noob. – Boogley Beegly May 04 '13 at 21:42
  • 1
    Every program has 3 types of memory: global (allocated once at start), dynamic (allocated using `new`), and stack. Stack memory is where your `automatic` variables like `objs` and `bacs` are stored. `bacs` is just too huge to fit on stack. Use `new`. –  May 04 '13 at 21:46
0

As I learned, when you request for space from memory, if the operation system, which you use(Windows in this case, I think), lets you to take it, you can take and use that space.

For some reason, Windows may not be letting you to take that memory for this situation. But I'm not that much expert in this field. I am stating this as a thought.

sha1
  • 153
  • 7
  • You do not allocate memory on stack; you just know the base address and limit. When stack pointer register (current stack top) overruns that limit, "stack fault" happens. This situation cannot be handled (you have no stack), and program just "stops working". OS could be more informative on this, though. –  May 04 '13 at 21:53
0

The default stack size (windows visual studio 2005, probably others keep the same number) is 1MB, check out http://msdn.microsoft.com/en-us/library/tdkhxaks%28v=vs.80%29.aspx to change it

ulimit in linux to change it.

The heap solution is valid too, but in your example you don't need heap. Requesting heap memory to the OS for something that won't escape the current function is not a good practice. In assembler the stack is translated just to a bigger subtraction, heap is requested thru other methods that require more processing.

elvena
  • 411
  • 3
  • 5
  • What if you needed a huge number of objects? (Even though you probably never would need more than 100000) – Boogley Beegly May 04 '13 at 21:52
  • Well, the stack is for holding temporary stuff that should be forgotten when we return to the caller (Or exit the software of course :p), so, the same thing applies. Now, if you don't know how much space it could use and you don't have any way to calculate it, would be more "bullet proof" to use heap to avoid the error you got in a critical application which of course, doesn't mean that is the best thing to do. – elvena May 04 '13 at 21:58