Message-ID: <MAPI.Id.0016.00333138303633303030303930303051@MAPI.to.RFC822>
In-Reply-To: <9907030532.AA16230@clio.rice.edu>
References: Conversation <Pine DOT SUN DOT 3 DOT 91 DOT 990701122605 DOT 10503A-100000 AT is> with last message <9907030532 DOT AA16230 AT clio DOT rice DOT edu>
Priority: Normal
X-MSMail-Priority: Normal
X-Priority: 3
To: djgpp-workers AT delorie DOT com
Cc: sandmann AT clio DOT rice DOT edu
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, 03 Jul 99 16:45:13 +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:

> Eli Zaretskii wrote:
>
> > You should be able to achieve the same effect with
> > `_CRT0_FLAG_FILL_SBRK_MEMORY', it also zeroes out all allocated
> > memory.
>
> If setting this flag causes it to work, its a smoking gun that
> there is a program bug.

I've tried this flag on CC1.EXE, but unfortunately, the error
was still there. Instead I think there's some error in the handling of
pointers >2Gb, and the error only happens in some very rare cases.

Probably it shows up on win3.11, because it seems that win3.11
doesn't free all memory automatically when a program exits,
only some of the allocated blocks are freed.

Then there may be lots of small free holes, which may be allocated
by malloc but only when the requested size is small enough to fit.
This may be the reason to why malloc returns blocks in reversed
order sometimes: The first sbrk call (1 Mbyte CC1 code and data
segment) is located at a rather high physical address, whereas
subsequent small malloc's can well be located at lower physical
addresses provided that the memory is fragmented enough.

On the other hand, win95 probably handles memory in another way
and frees all memory blocks automatically on program exit, so we
don't have the same situation there.

I think the reason that unix-sbrk acts as a work-around is
because it resizes a single memory block which in effect makes
malloc consistently return addresses <2Gb.

Any other ideas welcome,

Erik