Re: [Chicken-users] Unbounded stack growth

[Jim Ursetto]

It seems that compiling with clang (llvm 3.0)
prevents the crash, at least for values up to 20 million, on
OS X and Linux.  Any higher and I start to hit swap.
I don't know why this works.

Plain gcc on linux, and llvm-gcc (llvm 2.7) on OS X 10.7, do crash
at about 600k here w/ stack ulimit 8M.  Based on your results
I am guessing your stack ulimit is 4M.

Tried removing __attribute__((noreturn)) from chicken.h, as is done
for clang and it made no difference, as you'd expect.  Only
other difference from gcc is the stack pointer retrieval code but
that is identical between clang and llvm-gcc.  So I have to
assume LLVM 3.0 has something to do with the crash avoidance,
which could very well be luck.

Tested with Chicken 4.7.0.6.

Jim

On Jul 11, 2012, at 12:23 PM, Marc Feeley wrote:

> I have been experimenting with the Spock Scheme to JavaScript compiler.  I 
> encountered a bug in its implementation of the Cheney on the MTA approach to 
> tail-calls and continuations.  The bug also exists for Chicken.
> 
> In the Cheney on the MTA approach there needs to be a check, at regular 
> intervals, of the stack size, so that the stack can be GC'd using a 
> throw/catch or longjmp/setjmp.  Chicken (and Spock) perform this check at the 
> entry of Scheme functions.  For correctness, it must also be performed at the 
> *return point* of every non-tail call.  This is because the code has been CPS 
> converted, so a Scheme return is actually a C (or JS) *call* to the 
> continuation function, which grows the stack.
> 
> Here's a simple example where this matters :
> 
> ;; File: even.scm
> 
> (define (even n)
>  (if (= n 0)
>      #t
>      (if (even (- n 1)) #f #t)))
> 
> (print (even (string->number (car (command-line-arguments)))))
> 
> and a shell transcript of the behavior on a Mac OS X machine :
> 
> % csc even.scm
> % ./even 111111
> #f
> % ./even 200000
> #t
> % ./even 300000
> Segmentation fault: 11
> 
> The segmentation fault is due to a C stack overflow.
> 
> In this example, there will be an arbitrarily long sequence of C calls (in 
> the unwinding of the recursion to even) with no Scheme call, so stack size 
> checks will not be performed during the unwinding, yet the C stack grows 
> during the unwinding.  There is no stack overflow during the winding phase of 
> the recursion because the stack size checks are performed at regular 
> intervals (at each entry to even).
> 
> I believe the fix should be simple (i.e. a stack size check should be added 
> to return points).
> 
> Marc
> 
> 
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/chicken-users