From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9906242330.AA14501@clio.rice.edu>
Subject: Re: Re: gcc-crash - and a possible solution
To: erik2 DOT berglund AT telia DOT com (Erik Berglund)
Date: Thu, 24 Jun 1999 18:30:41 -0600 (CDT)
Cc: eliz AT is DOT elta DOT co DOT il, djgpp-workers AT delorie DOT com, pavenis AT lanet DOT lv,
        erik2 DOT berglund AT telia DOT com
In-Reply-To: <MAPI.Id.0016.00333138303633303030303930303039@MAPI.to.RFC822> from "Erik Berglund" at Jun 24, 99 05:54:06 pm
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
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.

> Whenever I try Unixy sbrk, it will consistently give me addresses
> below 2 Gbyte, and CC1.EXE will consistently work,
> not a single error since 2 Jun 1999, when I first started
> to examine the Unixy sbrk hypothesis. It may or may not
> be the final solution, but it probably has something to do
> with the error, anyway.

There is a long discussion someplace on the merits of each type
of sbrk.  I personally think the unixy sbrk() is the right
way to go usually - but some DPMI provider have problems with
the block resize command or limit you to 1/2 your virtual
address space (or less) since they copy memory.  You also can't 
use nearptrs with it.

> Do you know if win95 can give addresses above 2 Gbyte?

Absolutely.  Someplace (probably on a crashed disk) I had a
procedure to generate a sequence of calls (in two windows)
which would generate this address wrap feature.  I had a
mini test for it to make sure software worked in the V2.0
beta days.

Try this:
1) create two dos windows
2) run a program in window 1 that takes about 1Mb of memory, 
   then asks for a keystroke
3) run a second program in window 2 that asks for a keystroke
4) exit program from window 1
5) Continue program in window 2, sbrk() some 200K chunks or
   something and look at the addresses.  Window 2 will reuse
   window 1's address space (usually lower) when it exits.

> Maybe Microsoft has improved the memory allocation, so it
> simply doesn't happen any more (or happens very occasionally).

Less frequently, yes.