Odd Struct Problem resulting in Segmentation Fault

[Halsafar]

First off, its been awhile since I've had to post here I'm well into my first year of university taking computer science. I am already teaching a study group on saturday's and I'm highest over-all out of about 400 students.


So I got this struct:
struct Cell {
int iLife;
};

Class member:
Cell m_pBoard[50][50][50];


Now the program works fine like this. There is NO memory allocation, pointer manipulation, nothing special. I never do anything funky to m_pBoard, it is always accessed like: m_pBoard[x][y][z].iLife for example.

If I change the struct, even a bit:
struct Cell {
int iLife;
int iLife2;
}

The entire program runs into Segmentation faults, SDL deploys its parachute, I get a pointer access error. However it is apparently all stuff which the SDL and OpenGL can continue to render around... Altho since the Board of Cells is messed up it doesn't look very well.

Honestly, I can post the entire code if you want but I promise, the array m_pBoard is only used in a few loops, and only iLife is ever accessed in a normal fashion. I think it has to do with the 3D Array.

Any tips? Any advice? I haven't had a problem this stubborn in a long time.

[penagate]

I guess this is a game of sorts. Can you post a bit more information like what compiler you are using, what platform, etc. And what is "SDL". ?

My guess is it is something to do with alignment (and padding to meet such) but I could well be wrong.

[CornedBee]

SDL is the Simple Directmedia Layer, a very popular cross-platform multimedia library.

My guess is that it's either of these two:
1) You've got a dirty object file. Some part of your program hasn't been recompiled since the change of the structure, thus accessing the array incorrectly. Remove ALL object files, leaving only the source, and do a complete, fresh rebuild.
2) The raise from 500,000 to 1,000,000 bytes created some bad situation. Are you perchance allocating an object of this class on the stack? Because then you're almost guaranteed to get a stack overflow. Windows limits stack size to 1 MB, meaning that your program has a mere 48,576 bytes for everything else it needs to do on the stack - that won't suffice.

In general it's a bad idea to allocate anything larger then about 16 k on the stack.

[Halsafar]

I am programming this in/using:
- Emacs
- Linux (Mandriva specifically)
- Intel C++ Compiler (but it also compiles fine with g++)

1.) Dirty object file -- that was a theory of mine as well... I have cleaned the object files and recompiled from scrath, same problem.

2.) Okay now this is starting to make sense. Yes I am allocating it on the stack, it is a simple class instance variable declared like (Cell m_pBoard[50][50][50]). I didn't want to go through the trouble of allocating a 3D array on the heap and de-allocating it. Would you happen to know how much stack space the average linux kernel allocated per process? I am almost positive you are correct on that idea. I am going to allocate the entire array on the heap and see if that makes a difference.


Btw, I am programming a 3D remake of Jon Conways Mathematical Game Of Life.

[CornedBee]

Don't know about Linux - it's almost certainly configurable - but I would guess the default is the same as Windows.

[Halsafar]

Well that certainly was the problem.
Thanks CB!

[jim mcnamara]

malloc the array - don't put it on the stack as in auto (or local variable).

getrusage() will return your stack use and limits, but you have to be able to run the code first.

If you're running on a college owned box the limits on stack size are probably absurd - in the low direction. If they have not turned off ulimit

 ulimit -a

will show you how large your stack can grow.