From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<9602190316.AA10476@clio.rice.edu>
Subject:	Re: Segmentation problem in DJGPP v2
To:	oandico AT eee DOT upd DOT edu DOT ph (Orlando Andico)
Date:	Sun, 18 Feb 1996 21:16:05 -0600 (CST)
Cc:	djgpp AT delorie DOT com
In-Reply-To:	<Pine.SOL.3.91.960219105153.1406A-100000@gollum> from "Orlando Andico" at Feb 19, 96 10:56:31 am

> Yep; increasing the stack size to 4MB seemed to fix these problems. And 
> yes, the 1.12m4 version was crashing under Windoze too. But didn't I hear 
> that DJGPP v1 had an infinite stack? so what gives?

It has a 1Gb potential stack if *NOT* using a DPMI provider.  It's a DPMI 0.9
design problem more than anything else.

> Also: if I give it a 4MB stack, will that all be used? will it be paged? 
> ie can this program still run on a low-memory machine?

Only what your program needs will be used.  It depends on the DPMI provider
on if it gets paged or not (cwsdpmi doesn't commit pages to memory until
they are touched, but others do).  It may have problems on a low memory
machine depending on the DPMI provider, the amount of free disk space, etc.
With lots of free disk, it doesn't matter much with CWSDPMI.  But it would
be better to trim the 4Mb stack to something less if you can easily figure
out what that something less should be.

I have a subroutine that determines the maximum observed stack usage you could 
link in to find out; I also have a go32-v2 like program someplace that does 
this without linking.  But I'm too busy to find them right now, maybe later
this week.

> How common are these stack problems anyway?  This should be in the new FAQ.

Well, the number of bitches in V1.x under DPMI and the beta was zero from
what I remember, so I am somewhat confused at the new flurry of problems.
But as long as we have an easy fix, I guess we can live with it for a while.

- Raw text -