From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<9907060234.AA14450@clio.rice.edu>
Subject:	Re: Re: gcc-crash - and a possible solution
To:	erik2 DOT berglund AT telia DOT com (Erik Berglund)
Date:	Mon, 5 Jul 1999 21:34:04 -0600 (CDT)
Cc:	djgpp-workers AT delorie DOT com, pavenis AT lanet DOT lv
In-Reply-To:	<MAPI.Id.0016.00333138303633303030303930303057@MAPI.to.RFC822> from "Erik Berglund" at Jul 6, 99 00:59:18 am
X-Mailer:	ELM [version 2.4 PL20]
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> It looks like >2gb is a necessary but not sufficient condition.  In Win 3.11,
> from what I've observed, there is an irreversible "build-up" of >2gb.
> Do you know if this is the case in Win 95, too?  I mean, if you close
> all active Win 95 programs, thereby moving Win 95 back to its "idle" state,
> is there still a chance to get a malloc-block >2gb, in practice?

I saw some of this in the Win 95 final beta - occasionally picking
up 3.9Gb addresses.  But to be honest, I haven't monitored this
behavior at all since the summer of 1995, so I don't know how common
it is.  (I've been living on OpenVMS, HP/UX and Windows NT since then).

I remember one hack of sbrk() which just ignored and "tried again" when
DPMI returned a block which was "too low" :-)

I think it requires running 16-bit Windows apps on W95 - and maybe 
they are much less common than in 1995?

In any case, I wonder why the malloc chain is getting corrupted.

- Raw text -