Date:	Thu, 24 Jun 1999 11:58:52 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	erik2 DOT berglund AT telia DOT com, pavenis AT lanet DOT lv, djgpp-workers AT delorie DOT com
Subject:	Re: Re: gcc-crash - and a possible solution
In-Reply-To:	<9906231605.AA16115@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.990624115838.25071E-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 Wed, 23 Jun 1999, Charles Sandmann wrote:

> We have a new malloc since the previous version - I would double check
> it for signed/unsigned address clean and/or replace it with the old version.

Thanks, I will try to look into this.

At least judging by the traceback that was produced by the latest port
of EGCS, it was built with the new malloc, but the problem is still
there.  It is possible, however unlikely, that both the new and the
old malloc share some common bug wrt signed and unsigned, but it seems
more likely that the problem, if it's in the library, is in some other
place.

Another reason might be specific to GCC.  Since the crashes happen
inside obstack, it might be a good idea to see whether obstack code
assumes that the addresses it gets from malloc are contiguous and/or
consistently increasing.  If it does, then using the Unixy sbrk is
*the* solution.

Perhaps asking the EGCS maintainers about that would yield some useful
ideas.

- Raw text -