Message-ID:	<MAPI.Id.0016.00333138303633303030303930303057@MAPI.to.RFC822>
In-Reply-To:	<9907051617.AA14056@clio.rice.edu>
References:	Conversation <MAPI DOT Id DOT 0016 DOT 00333138303633303030303930303055 AT MAPI DOT to DOT RFC822> with last message <9907051617 DOT AA14056 AT clio DOT rice DOT edu>
Priority:	Normal
X-MSMail-Priority:	Normal
X-Priority:	3
To:	"Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Cc:	djgpp-workers AT delorie DOT com, pavenis AT lanet DOT lv
MIME-Version:	1.0
From:	"Erik Berglund" <erik2 DOT berglund AT telia DOT com>
Subject:	Re: Re: gcc-crash - and a possible solution
Date:	Tue, 06 Jul 99 00:59:18 +0100 (DJG)
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

Charles Sandmann wrote:

> I did lots of testing on Win 3.1 (not 3.11) but avoided multitasking there
> since it crashed frequently.  Win 95 definitely shows the >2gb address 
> behavior if you multitask the right programs.

Then >2gb may happen on Win 95, for instance by using two DOS boxes
(as pointed out in your message of 24 Jun 1999).  But maybe it's 
easier to produce >2gb on Win 3.11.  Also, it can be done without
multitasking, see below.

I suppose it all begins when DPMI starts allocating blocks in reversed
order because Windows internal linked lists have become re-ordered
for some reason, or a free block suddenly appears in lower memory.

I can reproduce >2gb by running WINHELP.EXE once and then
exit from it, leaving only PROGMAN.EXE and a DOS box running.
Then CC1 will get some >2gb, although it doesn't crash.

After running WINHLP32.EXE and exit, there is even more >2gb,
but no CC1 crash.

After running the special 3-program testcase and exit, there are
lots of >2gb and CC1 will crash. However, the "obstack objects" and
"obstack chunks" always seem to live at <2gb, so the problem
is presumably with some other malloc'ed data, living at >2gb.

So >2gb alone doesn't crash CC1, it also takes a certain RAM data 
setup plus a fairly large C-program to crash CC1.  Maybe there's a bug
in the Win 3.11 DPMI server, after all.  I'm continuing the research...
On the other hand, PMODE V1.2 and CWSDPMI r3 always work
nice and well.

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?

--

Erik

- Raw text -