Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: sandmann AT clio DOT rice DOT edu (Charles Sandmann),
        eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
From: Nate Eldredge <nate AT cartsys DOT com>
Subject: Re: A better stack dump
Cc: djgpp-workers AT delorie DOT com
Date: Wed, 27 May 1998 18:10:57 -0700
Message-ID: <19980528011049.AAA28554@ppp100.cartsys.com>
Precedence: bulk

At 06:54  5/26/1998 -0600, Charles Sandmann wrote:
>> On Mon, 25 May 1998, Nate Eldredge wrote:
>> > How about his other idea, that the page below the end of the stack be
unmapped?
>> 
>> I don't recall the particulars.  How should this work, since what's below 
>> the stack is usually the locked stack used for exception processing?  How 
>> do you unmap that and still get everything to work?
>
>I suggested the last page aligned page in the stack be unmapped.  In the worst
>case that would result in 8K less stack. 

The stack size could be padded appropriately to fix that.

> It would not catch all errors - since
>a huge allocation might potentially step over the "dead" area and do 
>irreversible corruption.  It would also result in dreaded "page fault" errors
>which might be difficult to diagnose (we might have to add some AI to register
>dumps to look at esp/ebp for hints?).

Right, obviously one page is not going to catch everything (and programs
that do fluffy `alloca's are a major culprit), but it is better than nothing.

Eli just added a patch to have it print out the stack limit upon crashing,
which could be adjusted appropriately. The user could be instructed that if
esp < that value, they should increase their stack size, or check for some
stack bug (like unintended infinite recursion).

Nate Eldredge
nate AT cartsys DOT com