Message-ID: <MAPI.Id.0016.00333138303633303030303930303053@MAPI.to.RFC822>
In-Reply-To: <Pine.SUN.3.91.990701122709.10503B-100000@is>
References: Conversation <MAPI DOT Id DOT 0016 DOT 00333138303633303030303930303046 AT MAPI DOT to DOT RFC822> with last message <Pine DOT SUN DOT 3 DOT 91 DOT 990701122709 DOT 10503B-100000 AT is>
Priority: Normal
X-MSMail-Priority: Normal
X-Priority: 3
To: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp-workers AT delorie DOT com, pavenis AT lanet DOT lv, sandmann AT clio DOT rice DOT edu
MIME-Version: 1.0
From: "Erik Berglund" <erik2 DOT berglund AT telia DOT com>
Subject: Re: Re: gcc-crash - and a possible solution
Date: Sun, 04 Jul 99 02:32:53 +0100 (DJG)
Content-Type: text/plain; charset="ISO-8859-1"; X-MAPIextension=".TXT"
Content-Transfer-Encoding: 7bit
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

Eli Zaretskii wrote:

On Tue, 29 Jun 1999, Erik Berglund wrote:

> > plp = lp->prev;
> > 
> > The highest valid lp-value seems to be around 0x28a004,
> > and therefore we get a "Page fault" error 0004
> > when lp for some reason becomes 0x472450.
> 
> It would be nice to know how does this happen.  Perhaps that will
> unlock the problem.

Now I'm beginning to understand what's happening :-)
The 0x472450 value looked like ASCII, and it is actually the
textstring "P$G" complete with a finishing null byte! The
text comes from the end of my first environment variable:

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? Can it be found somewhere
between address 0 and 0x10a8 in CC1? Any clues?

I have kind of single-stepped obstack_free(),
and the error occurs when the while-loop is
doing the 2:nd local turn in a certain call. The calling
sequence is in flow_analysis in flow.c, it seems ok:

obstack_free(&flow_obstack, NULL_PTR);

The while-loop normally runs a total of 595 global turns,
measured from the startup of CC1, in my special test case.
In win3.11, the crash happens exactly at global turn 144,
which corresponds to local turn 2.

In plain DOS, works ok:
local turn 1: lp = 0x33a000   (lp->prev = 0x334000)
local turn 2: lp = 0x334000   (no crash)

In win3.11 DOS box, first lp-value looks ok:
local turn 1: lp = 0x29004   (lp->prev = 0x472450)
local turn 2: lp = 0x472450   (crash)

I have included obstack_free() below, with a *Comment*:

void
obstack_free (h, obj)
     struct obstack *h;
     POINTER obj;
{
  register struct _obstack_chunk*  lp;	/* below addr of any objects in this
chunk */
  register struct _obstack_chunk*  plp;	/* point to previous chunk if any */

  lp = h->chunk;
  /* 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))
    {
/*
*   *Comment*
*   Here I jump away for a while to a patched "data-probe" which
*   maintains a loop-counter and also puts interesting registers into a 
*   SVGA scratch register for later examination.
*
*   This was the only way to debug CC1, because if I try to do a single
*    fprintf or change the size of CC1, this peculiar error just vanishes
*   or jumps away to a completely different place.
*/
      plp = lp->prev;
      CALL_FREEFUN (h, lp);
      lp = plp;
      /* If we switch chunks, we can't tell whether the new current
	 chunk contains an empty object, so assume that it may.  */
      h->maybe_empty_object = 1;
    }
  if (lp)
    {
      h->object_base = h->next_free = (char *)(obj);
      h->chunk_limit = lp->limit;
      h->chunk = lp;
    }
  else if (obj != 0)
    /* obj is not in any of the chunks! */
    abort ();
}

End of included program.

Erik