Date:	Wed, 23 Jun 1999 11:30:10 +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:	pavenis AT lanet DOT lv, djgpp-workers AT delorie DOT com,
	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject:	Re: Re: gcc-crash - and a possible solution
In-Reply-To:	<MAPI.Id.0016.00333138303633303030303930303039@MAPI.to.RFC822>
Message-ID:	<Pine.SUN.3.91.990623112921.13893J-100000@is>
MIME-Version:	1.0
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

Note that I cc: this and following messages to Charles Sandmann, in
the hope that he could help us figure out these crashes.

On Tue, 22 Jun 1999, Erik Berglund wrote:

> I was wondering about the "e", shouln't it be 0xffffffff instead of
> 0xfffeffff?

No.  The former is -1, which disables memory protection.  The latter
is a valid limit, it just looks weird.

> And I wonder why CC1.EXE sets such a high limit, and thereby effectively
> disables the memory protection?

When you use non-Unixy sbrk, the limit might need to be high because
the DPMI server allocates memory in several non-contiguous chunks that
might be far apart in the linear address space.  But that doesn't
disable memory protection because parts of the address space that
don't belong to any allocated chunk will trigger a Page Fault, just
like the one you see.

> I made a small test program which reads from an invalid address, to get
> a "normal" crash dump. I got, for %cs (Windows DPMI was used):
> 
> %cs sel=0xb7, base=0x815f3000, limit=0x000affff
> 
> Here, the %cs-limit has a more "normal" value, which I can understand.
> Why does CC1.EXE have to set the limit all the way up to
> the "unnormal" value 0xfffeffff?

Because cc1 allocates more memory at startup than small test programs
(cc1 has much more code and data), and the Windows DPMI server needs
to find enough of free memory to satisfy the requests.  Evidently, the
small test program would settle for a single chunk, while cc1 needs
several non-contiguous chunks.

I have the same situation with several large programs on Windows 95,
but they never caused any crashes.  So this ``unusual'' limit is not
the immediate cause of the crash.  Some other factor must be at work
here.

But once again, I don't think stack is your problem here, since `free'
has nothing to do with stack, unless cc1 overflowed its run-time
stack.  However, the stack overflow hypothesis doesn't seem to be
valid here, since (1) the latest EGCS binary, which has a 1.5MB stack,
also crashed in the same place in `free', and (2) the registers' dump
that you posted shows a very low stack usage, about 8KB.

So I think the problem is not with stack but with the heap.  The heap
is the first place to look for problems when the crashes are inside
`malloc' or `free'.

- Raw text -