[Gcl-devel] Re: seg fault from stack overflow

[Camm Maguire]

Greetings!

This stems from an overflow of the C stack, which is used in place of
the lisp value stack when declamations are in force.  

1) 2.7.0 has an enormous default C stack, so the process as written
       completes.  Larger numbers run forever and start swapping.  It
       has always been a question in my mind whether GCL should assume
       such things are mistakes and quit earlier, or proceed untill
       absolute exhaustion.  The latter, which is the current
       behavior, is best all things considered, IMHO.
2) There is a simple backport from 2.7.0 which catches a continuable
       SEGFAULT error using the C routine sigaltstack.  If you want to
       try this out in 2.6.7, I can send it to you.  Unfortunately,
       there is as yet no easy way to distinguish between a segfault
       on the C stack and one on the heap for use in the error
       message, though I have some ideas.  Please let me know if you
       consider this relevant.
3) If the C stack overrun happens within a GC mark, all hope is lost,
       and the current 2.7.0 behavior aborts.  If you see a way to
       continue in this case I'd be most interested.

Take care,

Matt Kaufmann <address@hidden> writes:

> Hi, Camm --
> 
> Consider the following (integer quotient) function, which quite
> legitimately causes the stack overflow shown:
> 
>   >(defun foo (i j)
>      (if (< i j)
>        0
>        (+ 1 (foo (- i j) j))))
> 
>   FOO
> 
>   >(compile 'foo)
> 
>   Compiling gazonk0.lsp.
>   End of Pass 1.  
>   End of Pass 2.  
>   OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
>   Finished compiling gazonk0.lsp.
>   Loading gazonk0.o
>   start address -T 0x84196e0 Finished loading gazonk0.o
>   #<compiled-function FOO>
>   NIL
>   NIL
> 
>   >(foo 1000000 1)
> 
>   Error: Value stack overflow.
>   Fast links are on: do (si::use-fast-links nil) for debugging
>   Error signalled by EVAL.
>   Broken at FOO.  Type :H for Help.
>   >>
> 
> Unfortunately, if we proclaim the function before compiling, we get a
> seg fault instead; I wonder if you can suggest an easy patch that
> would avoid this.  Here is a log (from a new GCL session).  Both
> examples (above and below) are GCL 2.6.7 running on 32-bit linux.
> 
>   >(DECLAIM (FTYPE (FUNCTION (T T) (VALUES T)) FOO))
> 
>   NIL
> 
>   >(defun foo (i j)
>      (if (< i j)
>        0
>        (+ 1 (foo (- i j) j))))
> 
>   FOO
> 
>   >(foo 10 1)
> 
>   10
> 
>   >(compile 'foo)
> 
>   Compiling gazonk0.lsp.
>   End of Pass 1.  
>   End of Pass 2.  
>   OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
>   Finished compiling gazonk0.lsp.
>   Loading gazonk0.o
>   start address -T 0x84196e0 Finished loading gazonk0.o
>   #<compiled-function FOO>
>   NIL
>   NIL
> 
>   >(foo 1000000 1)
>   Segmentation fault
> 
> Thanks --
> -- Matt
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah