Date:	Tue, 6 Jul 1999 13:08:34 +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.00333138303633303030303930303055@MAPI.to.RFC822>
Message-ID:	<Pine.SUN.3.91.990706130811.17419D-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 Mon, 5 Jul 1999, Erik Berglund wrote:

> xmalloc-call number 609:
> The malloc itself goes well, but the data in the previously
> allocated block is changed during the malloc call.
> xmalloc:
>    dataprobe: @0x292004 = 0x292fec    
>    call malloc(), returns 0x294004
>    dataprobe: @0x292004 = 0x243d5450
>    return;

This seems to imply some corruption of the memory pool maintained by
malloc.  I would suggest to try to find out why does this happen.

> There is another possibility though: The previously
> allocated block may just have been accidently free'd
> and now malloc thinks it's free for use. Maybe it's a
> good idea to "dataprobe" all calls to free and realloc
> as well. But even so it's hard to explain the sudden
> appearance of the new interesting PROMPT=$P$G data.

It's not hard at all.  Using unallocated or uninitialized memory
always shows some chunks of text previously processed by the program.
As I wrote elsewhere, the startup code allocates memory for all
environment variables, so at some time all VAR=VALUE pairs are copied
to memory allocated by the program.

- Raw text -