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