Subject: [clisp-list] stack overflow -> into debugger?

From: Russell McManus <[email-masked]>
Date: Mon Feb 25 09:28:04 2002

Is there some way to get clisp to drop me into the debugger when I get
a stack overflow condition?

-russ

---

From: Sam Steingold <[email-masked]>
Date: Mon Feb 25 12:45:52 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] stack overflow -> into debugger?"
> * Sent on 25 Feb 2002 12:24:27 -0500
> * Honorable Russell McManus <[email-masked]> writes:
>

not really - debugger requires some stack too, and detecting an
"impending" stack overflow is much more expensive than detecting an
actual one.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Bus error -- please leave by the rear door.

---

From: Raymond Toy <[email-masked]>
Date: Tue Feb 26 09:01:28 2002

>>>>> "Sam" == Sam Steingold <[email-masked]> writes:

    >> a stack overflow condition?

    Sam> not really - debugger requires some stack too, and detecting an
    Sam> "impending" stack overflow is much more expensive than detecting an
    Sam> actual one.

Just a thought.  Have no idea if this would really work.

Assume that the end of stack is unwriteable memory and that's how
stack overflow is detected.  Make the actual stack somewhat smaller
than the allocated space, and make the extra space unwriteable.

On stack overflow, make the extra space writeable so we actually have
more space.  Continue.  When you exit the debugger, the extra stack
space is made unwriteable again.  If you blow the stack in the
debugger, you lose.

Would this work?

Ray

---

From: William Harold Newman <[email-masked]>
Date: Tue Feb 26 17:57:02 2002

> space is made unwriteable again.  If you blow the stack in the

I've been thinking of something like this in SBCL, except
  * not messing around with memory protection, but instead adding
    runtime checks on entry to functions compiled with high SAFETY, and
  * starting with some reasonably generous amount of "more space" for
    debugging, e.g. 1 Mbytes, then allocating half of it at each level of
    debugger recursion, so you have 500 extra kbytes the first time
    you screw up, then 250 kbytes the next time, and so forth.

> Would this work?

Dunno yet. SBCL version 0.7.1.23 (checked in 2002-02-21) compiles
%DETECT-STACK-EXHAUSTION calls into functions, but it
%DETECT-STACK-EXHAUSTION is just a no-op stub right now, and the
associated error-recovery machinery doesn't exist either. I've been
working on other things instead of finishing it. (I found the stack
overflow bug in my application before I finished the stack-overflow
handling in SBCL.:-)

-- 
William Harold Newman <[email-masked]>
"Look on my works, ye Mighty, and despair!" -- Ozymandias, King of Kings 
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C

---

From: Jason Dagit <[email-masked]>
Date: Tue Feb 26 18:22:03 2002

What about just doing everything on the heap?  I know I don't have the
best understanding of activation records, but if I'm not mistaken the
performance hit isn't signficant and you won't blow the stack, you'll run
out of heap :)

I know that in cmucl it's much harder to get a stack overflow.  Perhaps
looking into their code and seeing why this is the case would be a worth
while exercise.

Just an idea or two,
Jason

On Tue, 26 Feb 2002, William Harold Newman wrote:

> _______________________________________________
> clisp-list mailing list
> [email-masked]
> https://lists.sourceforge.net/lists/listinfo/clisp-list
>

---

From: William Harold Newman <[email-masked]>
Date: Wed Feb 27 06:17:13 2002

> performance hit isn't signficant and you won't blow the stack, you'll run

I was under the impression that the performance hit *is* significant
in general. In particular, in languages which support Scheme-like
CALL/CC (which could be implemented straightforwardly by implementing
the stack as a linked list of heap-allocated frames and letting the GC
decide when they're no longer used) it seems as though a lot of
cleverness is devoted to minimizing the use of the the natural
heap-based implementation because it's too slow.
 
Also, it looks to me as though, at least in implementations with
conservative GC (like SBCL and CMU CL on the X86), any mechanism for
recovering from heap overflow will tend to be messier and less
reliable than the proposed mechanism for recovering from stack
overflow.

> looking into their code and seeing why this is the case would be a worth

I think the default stack in CLISP may be much smaller than in CMU CL
or SBCL. I can't find it in the current manual page, but I thought I
remembered just a few megabytes for CLISP, while the defaults for
CMU CL and SBCL tend to be on the order of 64 megabytes.