Date: Sun, 4 Jul 1999 16:20:40 +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, pavenis AT lanet DOT lv, sandmann AT clio DOT rice DOT edu
Subject: Re: Re: gcc-crash - and a possible solution
In-Reply-To: <MAPI.Id.0016.00333138303633303030303930303053@MAPI.to.RFC822>
Message-ID: <Pine.SUN.3.91.990704162011.13333W-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk


On Sun, 4 Jul 1999, Erik Berglund wrote:

> PROMPT=$P$G
> 
> I've checked it: When I change the variable, the crash
> dump changes accordingly!
> 
> Next question to answer is how did this DOS-variable
> end up in my crash dump?

This text doesn't in itself mean anything, except that CC1 somehow
accesses uninitialized memory.  I'd speculate that the text comes from
the startup code that puts every environment variable into a malloc'ed
block in the environ[] array.  So either CC1 uses a free'd block
without initializing it, or it accesses an address which is in use by
environ[].

The question is: how does CC1 end up using that memory address?
 
> In win3.11 DOS box, first lp-value looks ok:
> local turn 1: lp = 0x29004   (lp->prev = 0x472450)

Where did this lp->prev pointer come from?

>   /* We use >= because there cannot be an object at the beginning of a chunk.
>      But there can be an empty object at that address
>      at the end of another chunk.  */
>   while (lp != 0 && ((POINTER)lp >= obj || (POINTER)(lp)->limit < obj))

Based on Charles' recommendations, I would suspect the comparisons
here, due to the signed/unsigned issue.  Perhaps it would be a good
idea to look at the values that are compared and see if that explains
something.

Btw, what is the definition of POINTER in the above line?