Date:	Mon, 21 Jun 1999 10:56:33 +0300 (WET)
From:	Andris Pavenis <pavenis AT ieva01 DOT lanet DOT lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	Erik Berglund <erik2 DOT berglund AT telia DOT com>, djgpp-workers AT delorie DOT com
Subject:	Re: Re: gcc-crash - and a possible solution
In-Reply-To:	<Pine.SUN.3.91.990621090535.17143C-100000@is>
Message-ID:	<Pine.A41.4.05.9906211035580.61974-100000@ieva01.lanet.lv>
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 Mon, 21 Jun 1999, Eli Zaretskii wrote:

> 
> 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.

libc.a already have malloc. So there is no need to use something else.
To be sure I checked: no redefinition of malloc() found in object files
(gcc and libiberty)
 
> 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?

I suggest to try on different machine.

I cannot be sure of course but I remeber similar problems with one machine
which has hardware problems (somebody put EDO RAM in motherboard
which doesn't seem to support it).
      -	almost all worked

      - I didn't run gcc on it as I used different machine for that 	
	I also didn't test that under Win311 only under plain DOS
	(machine were used for hardware control and there were no need
        to mess with Wincrap)

      -	one my application worked Ok when I built it with old Borland C++
	3.1 but randomly crashed when I built it with DJGPP. Linking it
	with some memory debugger (Fortify) showed that some "bit
	droppings" (some bits are randomly changed). I didn't saw this on
	any other machine (application has been tested on many beginning
	from 386SX to AMD K5). After replacing RAM problem disappeared.

      - Of course Windows itself is one of the best "memory tests" however
        I remeber situation when Windows is running Ok if booted but
	memory test by hymem.sys detects problems.

So summary: the hardware problems are highly unpredictable and may not be
	evident.
  	
      - running memory tests may not show problems even when they are
	there.	
 
Andris



> 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 -