EXC_BAD_ADDRESS when adding more local variables in C

Question

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!

Can you post the source of bst_height_node(), it seems that you're free()'ing stuff you didn't allocate. — yan
How can this give a memory footprint of 1 MB? You are allocating one million integers for srch, this should be 4 MB alone (or 8 MB on 64 bit). However, if you are exceeding the stack, you should get a different error message. You can easily test this by increasing one of your predefined sizes. — Thalur
Activity Monitor must be lying to me then, anyways, increasing the macros doesn't break it, which is the weird part. Only adding new variables does — Greg Flynn
I love it when we get a stack overflow question on Stack Overflow... — Paul R
Hmmm ... try initializing your arrays: int rands[SIZE] = {0}, dels[dSIZE] = {0}, ... just for kicks — pmg

flolo flolo · Accepted Answer · 2011-03-31T13:49:18

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)

EXC_BAD_ADDRESS when adding more local variables in C

3 Answers