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

[Camm Maguire]

Greetings!

Matt Kaufmann <address@hidden> writes:

> Thank you, Camm.  Regarding #2 ("If you want to try this out in 2.6.7,
> I can send it to you."), I'd be interested in trying it out if it's
> just a bit of Lisp code that I can compile into ACL2, and include with
> later ACL2 distributions so that users don't lose their ACL2 sessions
> with C stack overflows.
> 

Alas, this one requires a patch in C, albeit small.  I'll endeavor to
get this into the 2.6.8pre tree.

Take care,

> Thanks --
> -- Matt
>    Sender: address@hidden
>    Cc: address@hidden, address@hidden, address@hidden
>    From: Camm Maguire <address@hidden>
>    Date: 03 May 2007 16:06:17 -0400
>    X-SpamAssassin-Status: No, hits=1.3 required=5.0
>    X-UTCS-Spam-Status: No, hits=-150 required=200
> 
>    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
> 
> 
> 

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