Date:	Thu, 8 Jul 1999 09:55:45 +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:	djgpp-workers AT delorie DOT com, sandmann AT clio DOT rice DOT edu
Subject:	Re: gcc-crash - and a possible solution
In-Reply-To:	<MAPI.Id.0016.00333138303633303030303930303059@MAPI.to.RFC822>
Message-ID:	<Pine.SUN.3.91.990708095509.21287K-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

On Thu, 8 Jul 1999, Erik Berglund wrote:

> What seems to be the strange thing to me, is how a fixed point in
> the heap (0x292004) can change this way, as a side-effect
> of malloc or morecore. Even if free(0x292004) was accidently
> called, malloc itself wouldn't copy new data in it?

No, malloc doesn't write anything to the block when it's freed, except
the place where the link to the next free block is stored.

> Finally, I did one more observation:  The error disappears when
> I turn off "Internal Cache" in BIOS setup, but then the compilation
> will take 5 minutes instead of 5 seconds...

Last time I saw strange problems that disappeared when the cache was
turned off, it was a case of a bad motherboard: the system clock was
driving the memory chips too fast, and some of the SIMMs were
sometimes not keeping up.  Interestingly enough, the problem was
detected by GCC (crashes during compilation), although I think it was
on plain DOS, not in Windows.

Are you sure this is not what happens here?  I think it might be a
good idea to run your test case on another machine, unless you find
bugs in malloc.

- Raw text -