scsh-users
[Top] [All Lists]

Re: heap overflows (Was: C-c transactions)

To: mmc@maruska.dyndns.org (Michal Maru¹ka)
Subject: Re: heap overflows (Was: C-c transactions)
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: Sat, 13 Apr 2002 16:52:02 +0200
Cc: scsh-bugs@zurich.ai.mit.edu
>>>>> "Michal" == Michal Maru¹ka <mmc@maruska.dyndns.org> writes:

Michal> Martin Gasbichler <gasbichl@informatik.uni-tuebingen.de> writes:

>> >>>>> "Michal" == Michal Maru¹ka <mmc@maruska.dyndns.org> writes:

>> >> (interrupt-in-set? (enabled-interrupts)
Michal>                    interrupt/int)
Michal> Scheme48 heap overflow

>> This is not a bug, you just confused the order of the arguments.

Michal> I keep confusing order, but i consider heap overflow
Michal> in scheme VM a bug.

Michal> today i happened to this:

Michal>    (error 'diff diff)

Michal> skips to the handler:

Michal>  (lambda (c next)
Michal>     (logformat "exception: ~s  ~s-> escaping the loop\n"
Michal>                c (nth 1 c))
Michal>   (cont #f))


Michal> i was getting another heap overflow, just to discover  NTH's proper 
arguments.
Michal> s48 seems fragile to me.

I'm not sure I see exactly what you're doing, but I wonder how any
language implementation should handle infinite non-tail-recursion more
robustly.  What's a stack overflow in other language implementations
is a heap overflow in Scheme 48, so no big difference there.  The
alternative is growing the heap until it takes up all virtual memory.
This I would consider much more fragile.

We're actually thinking about detecting infinite non-tail recursion in
the context of a new memory management system for Scheme 48, but it's
not a trivial issue, and not one many others address.

PS: You did notice NTH is deprecated in favor of LIST-REF, right?

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

<Prev in Thread] Current Thread [Next in Thread>