C++ stack overflow

Depends on the maximum stack size, you are after all requesting a 12 MegaByte array on the stack.

Yeah, sounds likely. It's usually a bad idea to allocate that much data on the stack

I'm generating a perlin noise texture, so i'm freeing the array after the texture generation. How do i increase the stack size ?

In vs.net its under your link settings\System. Why don't you just dynamically generate this memory and be done with it??

CHeers
Chris

I think it would be easier to use new (or if you use C malloc) and when your done with it, you use delete (or if you use C free).

On a multithreaded 32-bit platform, stack sizes are going to be limited. This is because there is relatively little address space available, so one thread's stack would crash into the next one's otherwise.

On a single-threaded 32-bit system, the stack should be able to be dynamic. I have no idea if win32 (or the normal C runtime etc) supports this however.

Stack size can probably be set at thread-creation time. Because the main thread is created when the app starts, its stack size needs to be set at compile time.

On 64-bit platforms, if it's supported, the maximum stack size per thread should be very large and dynamically allocated up to that limit. I've no idea if this is implemented in win64 however.

Mark

Well, i dont know how to use malloc with an array ...

Like so:


Note that this is not necessarily the best way to go about managing your texture. (A single-dimensional array using calculated offsets would probably be better.)

On Windows the default user stack size is 1 Mb.

To "mallocate" memory for this array: int test1[1024][1024][3];

int ***test1 = malloc(sizeof(int**) * 1024);
for ( int i=0; i < 1024; i++) {
test1 = malloc(sizeof(int*) * 1024);
for ( int j=0; j < 1024; j++) {
test1[j] = malloc(sizeof(int)*3);
}
}

And to clean up

for ( int i=0; i < 1024; i++) {
for ( int j=0; j < 1024; j++) {
free(test1[j]);
}
free(test1);
}
free(test1);

...

YMMV

// edit - looks like I was beatin to the punch

With a rectangular array meant for representing a bitmap, you'd better off just allocating a simple one-dimensional array and doing the index calculations by hand. Like this:

int *array = new int[1024 * 1024 * 3];// or in C: int *array = malloc(1024 * 1024 * 3 * sizeof(int)];// Here's how you'd write 123 to the index x,y,zarray[1024*1024*z + 1024*y + x] = 123;delete [] array; // important to remember the []// or in C: free(array);

i only use c++, but isn't this possible in c?

Quote:

Original post by Anonymous Poster make it static?

Yes!
This is all you need to do:

static int test1[1024][1024][3];

Which will move it from the stack to the heap, where it should fit just fine.
You needn't go to the trouble of using malloc.

Quote:

Original post by Sharlin With a rectangular array meant for representing a bitmap, you'd better off just allocating a simple one-dimensional array and doing the index calculations by hand. Like this: int *array = new int[1024 * 1024 * 3];// or in C: int *array = malloc(1024 * 1024 * 3 * sizeof(int)];// Here's how you'd write 123 to the index x,y,zarray[1024*1024*z + 1024*y + x] = 123;delete [] array; // important to remember the []// or in C: free(array);

I'd second this particular approach. It also fragments memory less.
And since you're using a nice power-of-2 number, you could get away with bitmath for multiplication. Though, something tells me that that particular optimization should already be done by the compiler itself.

Really thanks for all this inputs !

Quote:

Original post by iMalc Quote: Original post by Anonymous Poster make it static? Yes! This is all you need to do: static int test1[1024][1024][3]; Which will move it from the stack to the heap, where it should fit just fine. You needn't go to the trouble of using malloc.

yes but if its static you've 12Megs hanging around with no way to free it.

are you going to use this data regularly?

Quote:

Original post by iMalc Quote: Original post by Anonymous Poster make it static? Yes! This is all you need to do: static int test1[1024][1024][3]; Which will move it from the stack to the heap, where it should fit just fine. You needn't go to the trouble of using malloc.

It probably won't move it to the heap, it will most likely move it to a data segment of the executable. This can bloat the actual executable by 12 megs if you have a low quality compiler or run it on an operating system that doesn't support load time allocation of data segments. Either way it stays around taking up space for the entire execution of the program, even during times when you aren't using it.

Heck, I never thought a compiler would be stupid enough to put it into the exe, when a static initialisation wasn't even specified! That's certainly a good enough reason not to though.
Yes I was assuming that it was something that was used a lot.