dan@lclark.UUCP (Dan Revel) (11/23/89)
I have been getting SysError #28 ('dsStkNHeap') stack overflow errors
from my Think C 4.0 program when I run it on either a 1 meg SE or a
Mac Plus, my 5 meg IIx development system runs things just fine. I
went and cleaned up a couple of large variable that were being allocated
on the stack and that seems to have helped. I thought it would be nice
to know how to change the stack size, any pointers? :-)
I tried using GetApplLimit and SetApplLimit just after calling MaxApplZone
at the beginning of my program, I adjusted the limit downwards thinking
that that would shrink the heap size and thereby allow a bigger stack.
all I got for my efforts was a bomb!
While I'm here, is the reason that the errors don't show up on the IIx just
that the stack-sniffer doesn't catch them, or is there some other possibility?
Thanx, and have a happy Thanksgiving!
Dan
--
dan@lclark
tektronix!reed!lclark!dan Dylsexics untie! (-|dan@lclark.UUCP (Dan Revel) (11/23/89)
It just occured to me to mention that the IIx system that doesn't bomb was running under Multi-Finder. Sorry about the multiple posting... -- dan@lclark tektronix!reed!lclark!dan Dylsexics untie! (-|
earleh@eleazar.dartmouth.edu (Earle R. Horton) (11/24/89)
In article <802@lclark.UUCP> dan@lclark.UUCP (Dan Revel) writes: ... >I tried using GetApplLimit and SetApplLimit just after calling MaxApplZone >at the beginning of my program, I adjusted the limit downwards thinking >that that would shrink the heap size and thereby allow a bigger stack. >all I got for my efforts was a bomb! You have to call SetApplLimit first, then MaxApplZone. SetApplLimit sets the application heap limit, while MaxApplZone expands the heap to this limit. It is not logical to call them in the other order. Instead of using GetApplLimit, you can calculate the desired heap end address by subtracting the desired stack size from the current stack pointer while in the top level of your program. This easy in assembler. In a high level language, the same effect may be obtained by taking the address of a local variable, thusly: main() { /* some vars */ long stackframeend; /* Last auto var in main. */ SetApplLimit( (char *)(& stackframeend) - DESIRED_STACK_SIZE ); MaxApplZone(); This is what I always do. Note that GetApplLimit is not a real trap call, but is either glue or inline code to dump a low memory location. If low memory globals go away, GetApplLimit dies until you get new interface files, and you will have to recompile and reship your application. My method will always work, and is more direct. Even more direct is the following, if you can assemble code: movea.l a7,a0 suba.l #DESIRED_STACK_SIZE,a0 _SetApplLimit _MaxApplZone Earle R. Horton