X-Authentication-Warning: ieva01.lanet.lv: pavenis owned process doing -bs
Date: Sun, 4 Jul 1999 17:27:39 +0300 (WET)
From: Andris Pavenis <pavenis AT 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,
        sandmann AT clio DOT rice DOT edu
Subject: Re: Re: gcc-crash - and a possible solution
In-Reply-To: <Pine.SUN.3.91.990704162011.13333W-100000@is>
Message-ID: <Pine.A41.4.05.9907041719210.31396-100000@ieva01.lanet.lv>
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



Perhaps it would be usefull to link gcc with modified version of malloc
which fills malloced memory with some non zero value (eg. 0xA3).
Currently (up to approx July 10th)  I'll not hack similar things, so
somebody could try that.


Andris

On Sun, 4 Jul 1999, Eli Zaretskii wrote:

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