Message-ID:	<MAPI.Id.0016.00333138303633303030303930303050@MAPI.to.RFC822>
In-Reply-To:	<Pine.SUN.3.91.990701122709.10503B-100000@is>
References:	Conversation <MAPI DOT Id DOT 0016 DOT 00333138303633303030303930303046 AT MAPI DOT to DOT RFC822> with last message <Pine DOT SUN DOT 3 DOT 91 DOT 990701122709 DOT 10503B-100000 AT is>
Priority:	Normal
X-MSMail-Priority:	Normal
X-Priority:	3
To:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Cc:	djgpp-workers AT delorie DOT com, 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:	Fri, 02 Jul 99 18:03:08 +0100 (DJG)
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

Eli Zaretskii wrote:

> Did you see whether the allocated blocks use high addresses in this
> modified version?  If not, you indirectly worked around the problem by
> feeding `sbrk' with the low addresses, like in Unixy sbrk case.

Now I have checked the addresses and it turns out that
xmalloc returns mixed high and low addresses for 
alloc-delta = 128, 256 or 512 kbyte.

xmalloc returns only low addresses for
alloc-delta = 1 Mbyte.

Another important observation that I made during this test:

For alloc-delta = 512 kbyte, CC1 may crash the usual way
for a large infile!

So my hypothesis (H0) about too many DPMI 0x501-calls was
probably wrong.

Instead, the other hypothesis (H1) about some problem with
unsigned/signed pointer arithmetics sounds more and more likely,
because when the error shows up, it's always accompanied
by at least some high addresses from xmalloc.

And unix-sbrk still works, and I assume it always returns
addresses between 0x10a8 and 0x7fffffff, and that would
support the H1 hypothesis as well.

I'm going to check the assembler- and C-code in CC1,
libc.a and libgcc.a for any unsigned/signed errors.
For instance, here's one situation I could think of:

cmpl $0,%eax   ; %eax is a pointer
jg L1      ; it should be "jnz" or "ja"

or:

if ((int)p > 0) func();   /* the typecast should be unsigned */

or a special, funny bug:

while (p < q) {   /* p and q are pointers, q happens to be 0 */
   func();
   p++;
}

The above normally works, but not if q is 0!
q could possibly be a valid pointer with the value of 0 
if xmalloc just returned a 32 kbyte buffer
starting at p = 0xffff8000 and q is set to point at the
end of this buffer by q = p + 32768;

Could there be any more error situations to look out for?

Erik

- Raw text -