Mail Archives: djgpp/1996/02/28/02:38:07
Reply to message 9341724 from J DOT ALDRICH6 AT GE on 02/27/96 9:52PM
Well. After my exuberant post of a few days ago, I had thought that
my "random crash" problems were behind me. My experience today,
however, has taught me the folly of assumption. Not only were the
crashes worse, but it appeared that several of my functions were
overwriting large chunks of permanent memory! After a lengthy session
with GDB, I have discovered the that the real problem I was having was
not overflowing my buffer variables, it was overflowing my stack. It
seems that in allocating the stack space necessary to store the local
variables in my function, the stack grew so large that it actually overwrote
segments of static storage!
According to GDB, the function's stack frame started at 0xd9b34.
I checked the address of the local variable buf, and it gave me an
offset of -266304. With a calculator, the address of buf became 0x98af4.
The static variable it was overwriting was located at address 0x96900,
and had a length of 13312 bytes. Simple arithmetic gives the answer -
the local variable got placed in the exact middle of the static variable.
My question is: Why didn't my program report a stack overflow error?
Is this a bug in GCC, or is it supposed to leave it up to me to detect
the possibility? I will admit that using 250K for local variables is a bit
excessive, and I have rewritten the functions so as to dynamically allocate the
required space, but still, shouldn't it have told me first? Is there a
compilation option that would cause it to report such errors?
In case anyone is curious, I compile with the following options (excerpted
from the Makefile):
gcc -c -g -O -D MSDOS -Wall *.c
gcc -O -lpc -o merc <lots of .o files>
Is this a bug, am I not compiling correctly, or is it just something I have to
be careful of?
If the latter, is there any way I can detect when I am running myself out of
stack space
except when the program crashes unexpectedly?
Thanks
John
- Raw text -