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: from "Erik Berglund" at Jul 6, 99 00:59:18 am X-Mailer: ELM [version 2.4 PL20] Content-Type: text 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 Precedence: bulk > 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.