Message-ID: <MAPI.Id.0016.00333138303633303030303930303043@MAPI.to.RFC822>
In-Reply-To: <9906242330.AA14501@clio.rice.edu>
References: Conversation <MAPI DOT Id DOT 0016 DOT 00333138303633303030303930303039 AT MAPI DOT to DOT RFC822> with last message <9906242330 DOT AA14501 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, erik2 DOT berglund AT telia DOT com
MIME-Version: 1.0
From: "Erik Berglund" <erik2 DOT berglund AT telia DOT com>
Subject: Re: Re: gcc-crash - and a possible solution
Date: Sat, 26 Jun 99 02:32:57 +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


> > I did some experimenting and printed out the addresses coming from
> > malloc-calls in CC1.EXE, there were several hundreds of them, and
> > some of them were below 2 Gbyte, and some were above 2 Gbyte,
> > it all came out in a random fashion.
>
> Not unexpected if you get some dpmi blocks returned below the
> original one.

No it's perfectly ok in theory, and malloc and CC1.EXE should work
just as well for any pointer between 1 and 4 Gbyte-1, in theory.

Maybe there is an error in win3.11:

Too many DPMI-requests with unordered blocks in one 
program could perhaps overflow the internal Windows tables,
and it's not indicated in the CF-flag from the DPMI-call.
That's just a theory. It might also be malloc, realloc or GCC.

Just some other experiments that I did recently:

1) I made an "improved" malloc.c (malloc, realloc, free),
which calls the old malloc, realloc, free, but also inits 
malloc'ed data to 0 and also copies the old
data in realloc to the new address. I rebuilt CC1.EXE
with it and it seems to work so far...

2) I rewrote malloc.c (malloc, realloc, free) from scratch,
so initially I allocate 16 Mbyte (using the old malloc),
and then just return an increasing pointer to the application.
free doesn't do anything at all. I rebuilt CC1.EXE
and everything seemed to work with this approach as well.

Now I think I will test 1) for a few days and see what's happening.

Erik