EXC_BAD_ADDRESS when adding more local variables in C

So I have a program that works, but when I add more local variables, it blows up.

Added code:

double prMaxT, prMinT, poMaxT, poMinT, linT;

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x0000000100001411 in bst_height (bst=0x0) at bst.c:72 72 return bst_height_node(bst->root);

flynn_p4(7171) malloc: *开发者_运维百科 error for object 0x7fff5fc00760: pointer being freed was not allocated * set a breakpoint in malloc_error_break to debug Abort trap

All variables:

#define SIZE 1000
#define dSIZE 500
#define RUNS 5000
#define SEARCH_WIDTH 1501
#define SEARCHES 1000000
//main()
int rands[SIZE], dels[dSIZE], srch[SEARCHES], pre_h[RUNS], post_h[RUNS], i, j, z, found = 0, total = 0;
struct timeval whole_start, whole_end;
double prMaxT, prMinT, poMaxT, poMinT, linT;
struct bst *pre_max, *post_max, *pre_min, *post_min, *linear, *trees[RUNS];

All of these give my program a memory footprint of ~1.2MB, so I've tackled all the leaks I could find. And the error isn't where gdb thinks it is in bst_height_node() since if I comment out the doubles, everything works.

So is there a limit to how much memory main() can have on the stack and am I exceeding it? I've moved the large arrays to global space and that hasn't fixed it, but more than anything I want to know what's going on rather than just a fix.

Build environment: gcc 4.2.1 on Mac OS X 10.6.7 - 2010 Macbook Pro (in case it's relevant)

//Edits: I solved this with the gcc flag -pedantic flag, which gave me:

gcc -pedantic -c -o bst.o bst.c gcc -pedantic -c -o main.o flynn_p4.c flynn_p4.c: In function ‘main’: flynn_p4.c:87: warning: ISO C90 forbids mixed declarations and code flynn_p4.c:131: warning: ISO C90 forbids mixed declarations and code gcc -pedantic -o flynn_p4 main.o bst.o

So my int declaration halfway through the function caused this, DOH!

Dont know what the default stack limit is. I am no MacOS user but considering that the underlying system is a unix, try in the shell a ulimit -a to list the process limits.

I would guess it has a hard limit somewhere in the kernel, but till reaching it you can increase your process stack limit with ulimit -s.

(But I must admit that I would expect a different error message in case it is really a stack overflow - it looks more like some null pointer stuff)

For chunks of data like that, I would certainly allocate them on the heap. It doesn't make much difference to your code whether you're storing pointers or arrays on the stack, but the world of difference to the stack size. Yes, there is a limit for the size of the stack.

And even if it did work, what if you (or worse, someone else) wanted to come back and change those size macros? Or what if you had two functions with large stack frames, which worked fine separately, but at a later date you decided to call one from another?

Adding the -pedantic flag to gcc revealed an out of place variable declaration partway through the function:

gcc -pedantic -c -o bst.o bst.c gcc -pedantic -c -o main.o flynn_p4.c flynn_p4.c: In function ‘main’: flynn_p4.c:87: warning: ISO C90 forbids mixed declarations and code flynn_p4.c:131: warning: ISO C90 forbids mixed declarations and code gcc -pedantic -o flynn_p4 main.o bst.o

-pedantic wins this round