SWANGER%AUDUCVAX.BITNET@CUNYVM.CUNY.EDU (03/16/88)
I am using MSC 5.0 to write a software package for my IBM PC clone. I am having problems with stack overflow. I've tried enlarging the stack with the /ST flag, but I'm approaching the 64k stack limit. My code is only about 500 lines or so, but when I get about three functions deep, the program dies with a stack overflow message. I'm using the large memory model, all of my arrays are dynamically allocated with calloc, I'm using a lot of integer variables (but not that many), and I'm using a lot of functions from the screen formatting package Vitamin C. Does anyone have any suggestions how I can get around this problem? Is there a way to increase the stack size past 64k, or is this an Intel curse? Is any data being put on the stack that could be put on the heap? I would appreciate any help anyone could give me. --------------------------- JCL - The Big Lie ---------------------------------- David Swanger Academic Computing Services 200 L Building Auburn University, AL 36849 Telephone: 205-826-4813 |-----------------------------------------| | | SWANGER@AUDUCVAX (BITNET address) | My opinions are my own ... etc. | | | --------------------------------------------------------------------------------
aland@infmx.UUCP (alan denney) (03/16/88)
In article <12416@brl-adm.ARPA>, SWANGER%AUDUCVAX.BITNET@CUNYVM.CUNY.EDU writes: > > I am using MSC 5.0 to write a software package for my IBM PC clone. I am > having problems with stack overflow. I've tried enlarging the stack with > the /ST flag, but I'm approaching the 64k stack limit. My code is only > about 500 lines or so, but when I get about three functions deep, the > program dies with a stack overflow message. I'm using the large memory > model, all of my arrays are dynamically allocated with calloc, I'm using > a lot of integer variables (but not that many), and I'm using a lot of > functions from the screen formatting package Vitamin C. Does anyone have > any suggestions how I can get around this problem? Is there a way to > increase the stack size past 64k, or is this an Intel curse? Is any data > being put on the stack that could be put on the heap? > > I would appreciate any help anyone could give me. > This info assumes that you are getting "Error 6000: Stack Overflow" at run time. I hope this is helpful. I ran into the equivalent error in MSC 4.0 (there it's called Error 2000; nice to see that the errors are somewhat backward compatible :-) ) This error has nothing to do (directly) with amount of code, but *data*. This usually means that the default segment (DGROUP) cannot accomodate all of its *initialized* data items *plus* the stack size (limit for any segment is 64K). Therefore, you have to either reduce stack size (not always feasible, or even wise) or move some data out of DGROUP. The first thing to try is to force some data out into another segment via the /Gt (Data Threshold) compile flag. For example, if you specify "/Gt512", any data item > 512 bytes will be relocated to another segment. (If you don't specify a number, 256 is assumed. If you omit the flag entirely, the value 32K is used, effectively forcing everything into DGROUP). For more info, see Section 6.6 of the MSC 5.0 user guide. > > ------------------------- JCL - The Big Lie ---------------------------------- > Academic Computing Services > 200 L Building > Auburn University, AL 36849 > Telephone: 205-826-4813 |-------------------------------------| Actually, I kinda miss MVS JCL - shell scripts aren't quite as dangerous! -- Alan S. Denney | {pyramid|uunet}!infmx!aland Informix Software, Inc. | CAUTION: This terminal makes wide right turns! Disclaimer: These opinions are mine alone. If I am caught or killed, the secretary will disavow any knowledge of my actions. -- -
bright@Data-IO.COM (Walter Bright) (03/17/88)
In article <12416@brl-adm.ARPA> SWANGER%AUDUCVAX.BITNET@CUNYVM.CUNY.EDU writes:
<I am using MSC 5.0 to write a software package for my IBM PC clone. I am
<having problems with stack overflow. I've tried enlarging the stack with
<the /ST flag, but I'm approaching the 64k stack limit. My code is only
<about 500 lines or so, but when I get about three functions deep, the
<program dies with a stack overflow message.
<Does anyone have
<any suggestions how I can get around this problem? Is there a way to
<increase the stack size past 64k, or is this an Intel curse?
In MSC, the stack and static data share the same segment. In other words,
SS == DS in all memory models. This means that if you have a lot of statically
allocated data, you reduce the available space for the stack. Check your
.MAP file to see how much space is being used in DGROUP.
My suspicion, though, is that you have a pointer bug. Try reducing your
program to the smallest possible one that reproduces the problem. Try
codeview on it, paying special attention to the values of SP, SS and DS.
No way you can have a stack >64k, this is wired into the CPU hardware.swh@hpsmtc1.HP.COM (Steve Harrold) (03/17/88)
Re Stack overflow Check how big your DOS environment variable area is. I seem to recall that this space gets added to your stack. Some of us, myself especially, allocate a large space (via /E: on the COMMAND.COM line in CONFIG.SYS) and forget about it. Periodically I get bitten. --------------------- Steve Harrold ...hplabs!hpsmtc1!swh HPG200/13 (408) 447-5580 ---------------------
Ralf.Brown@B.GP.CS.CMU.EDU (03/17/88)
In article <11480010@hpsmtc1.HP.COM>, swh@hpsmtc1.HP.COM (Steve Harrold) writes: }Check how big your DOS environment variable area is. I seem to recall that }this space gets added to your stack. Some of us, myself especially, }allocate a large space (via /E: on the COMMAND.COM line in CONFIG.SYS) and }forget about it. Periodically I get bitten. } }--------------------- }Steve Harrold ...hplabs!hpsmtc1!swh } HPG200/13 } (408) 447-5580 }--------------------- Actually, it's not how much you've allocated that matters, but how much is actually in use. When you EXEC a program, DOS creates an environment block that is just large enough to hold all the current variables plus the program's full name. The amount you allocate via /E only sets the size of the environment for the initial copy of COMMAND.COM. -- {harvard,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=- TalkNet: (412)268-3053 (school) ARPA: RALF@B.GP.CS.CMU.EDU |"Tolerance means excusing the mistakes others make. FIDO: Ralf Brown at 129/31 | Tact means not noticing them." --Arthur Schnitzler BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA -=-=- DISCLAIMER? I claimed something?
dave@westmark.UUCP (Dave Levenson) (03/18/88)
In article <12416@brl-adm.ARPA>, SWANGER%AUDUCVAX.BITNET@CUNYVM.CUNY.EDU writes: > > I am using MSC 5.0 to write a software package for my IBM PC clone. I am > having problems with stack overflow... > ...when I get about three functions deep... David: If you're not declaring large auto arrays, structs, or an incredibly large number of local variables, the most likely cause of stack overflow is endless recursion. If you have MSC 5.0, you probably have codeview. Can you cv your program, and watch the function calls? Can you watch the value of SP at each function call? That ought to help point the finger. -- Dave Levenson Westmark, Inc. A node for news. Warren, NJ USA {rutgers | clyde | mtune | ihnp4}!westmark!dave