Date:	Mon, 21 Jun 1999 09:07:44 +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:	Andris Pavenis <pavenis AT lanet DOT lv>, djgpp-workers AT delorie DOT com
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.990621090535.17143C-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 Sun, 20 Jun 1999, Erik Berglund wrote:

> > > Call frame traceback EIPs:
> > >   0x00175777 _free+119
> > >   0x00173755 _obstack_free+49
> > >   0x000dbcb6 _reload+3730
> > 
> > This looks like some code is overwriting a buffer allocated by
> > malloc, or freeing some buffer that is already freed.

On second thought, there's something else strange here: the address of
`free' is abnormally high.  Usually, it lives somewhere in the 0x1NNN
region, because the startup code calls it.

Andris, does GCC use an alternate version of malloc/free, like GNU's
malloc?  If so, then using Unixy `sbrk' *is* the solution, since
gmalloc expects the Unixy behavior and will break otherwise.

If GNU's malloc is not used, then how come `free' has such a high
address?

> Hmmm. Could it be an uninitialized stack variable somewhere in
> gcc?

Stack space isn't malloc'ed, it is allocated by a direct call to
`sbrk' in crt0.S.

> Because the error seems to depend on a certain program
> sequence previously run, that is, the state of the RAM bits
> (128 Mbyte, that is 1 Gbit).

Don't forget that the heap (the space used for malloc'ed storage) also
inherits whatever garbage was in RAM before, since DJGPP's `malloc'
doesn't zero out the allocated buffer (to prevent large run-time
penalties due to accessing the allocated memory).

- Raw text -