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)
Content-Type: text/plain; charset="ISO-8859-1"; X-MAPIextension=".TXT"
Content-Transfer-Encoding: 7bit
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

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