Date: Thu, 1 Jul 1999 12:26:40 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Erik Berglund <erik2 DOT berglund AT telia DOT com>
cc: Charles Sandmann <sandmann AT clio DOT rice DOT edu>, djgpp-workers AT delorie DOT com
Subject: Re: Re: gcc-crash - and a possible solution
In-Reply-To: <MAPI.Id.0016.00333138303633303030303930303043@MAPI.to.RFC822>
Message-ID: <Pine.SUN.3.91.990701122605.10503A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Sat, 26 Jun 1999, Erik Berglund wrote:

> 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...

Zeroing out the allocated buffer causes it to be paged into the
physical memory, which will probably cause different order of
addresses we get from the DPMI server.

You should be able to achieve the same effect with
`_CRT0_FLAG_FILL_SBRK_MEMORY', it also zeroes out all allocated
memory.