[Gcl-devel] Re: random segmentation violations

[Camm Maguire]

Greetings!

OK, here is an attempt at a quick reply as I see it -- if it is at all
unclear, please so state, and I will try to elaborate as time permits.

unsafe compilation should be ok when "the code is correct as written",
i.e. the programmer has explicitly done the type checking themselves.
Our system function code should fit into this category if properly
done.  For example, consider a function for 'elt 0':

(cond ((listp x) (car x)) ((vectorp x) (aref x 0)) ((check-type x
sequence)))

Here we don't want car to have to proceed a) through a separate
function call, and b) to check its generic argument again, as we have
already done this in our own code.  Likewise of course with aref
above, and for numeric code where the results are known to lie within
the same field, etc.

In principle, then, if each system function checks its call signature,
and then checks the types of its passed arguments explicitly where
necessary, the rest of the code should be fully optimizable if
"correctly written".  

This is just my weak understanding of the issue.  Why there are three
levels of safety, and the meanings associated to each level, is still
somewhat of a mystery to me.

Take care,


Robert Boyer <address@hidden> writes:

> > Yes!  These are all mistakes.
> 
> Thanks for your very clear and definitive reply.  I will
> then look and report more such problems if and when I can.
> 
> > but type checking must be done explicitly.
> 
> Ok, please explain to me, in kindergarten terms, what is the
> general, long term, GCL strategy for both (a) paying the
> cost of making these type checks in interpreted or SAFETY 3
> code and (b) yet running as fast as possible for compiled
> SAFETY 0 code?
> 
> An illustration for the case of SECOND, which I mentioned in
> email a few days ago, might get through my thick skull.
> 
> If in SAFETY=3 or interpreted code we always, somehow, test
> every arg to SECOND for correct type, then in SAFETY=0
> compiled code (or whatever setting we hope for as
> "fastest"), won't we slow things down a great deal?  In
> SAFETY=0 compiled code, I want to pay, in terms of time
> lost, for nothing except two idealized machine code
> instructions for one call to SECOND, which is to say, a CDR
> and a CAR, viz., the instructions that will fetch from
> memory the first (or, depending on the implementation, the
> second) full word after the address pointed to.  Safely
> testing for NILs or CONSes would seem to me to involve
> several more instructions no matter how we do it.  No type
> mechanism I can imagine is going to be good enough to infer
> that such tests are unnecessary.  (Very informally, by using
> SECOND, I am telling the world, when running in SAFETY=3,
> that this instruction is ok to do and just want to do it.)
> When I'm running compiled SAFETY=0, I just don't want such
> testing instructions to waste my time.  (If we could do such
> testing on the side, I mean in parallel, that is, at no time
> performance penalty, that would be good, in fact, very
> good.)
> 
> Thanks,
> 
> Bob
> 
> Here's some vaguely related, older correspondence about the
> function 'SECOND' referred to above, otherwise irrelevant.
> 
> 
> -------------------------------------------------------------------------------
> 
> >From boyer Thu Apr  6 16:19:45 -0500 2006
> From: Robert Boyer <address@hidden>
> To: address@hidden
> Subject: errors
> 
> Don't errors such as "in EVAL [or a callee]: Control stack overflow" on
> top-level forms to the read-eval-print loop such as
> 
>   (nth 3 'a)
>   (third 'a)
>   (symbol-macrolet (x))
> 
> seem rather harsh?
> 
> I think that in general, such serious errors, which can
> easily lead to segmentation violation, should not happen
> during a call of EVAL unless EVAL gets its hands on a
> compiled function that was compiled at safety less than 3.
> But which built in functions are compiled at less than
> safety 3?  I'd think none of them.
> 
> Anyway, I'm pretty sure that the following transcript shows
> a discrepancy between the treatment of (car (cdr x)) and
> (second x) that does not look right in a compiled safety=3
> situation.
> 
> Bob
> 
> -------------------------------------------------------------------------------
> 
> % cat foo.lisp
> (declaim (optimize (safety 3)))
> 
> (defun f (x) (car (cdr x)))
> 
> (defun g (x) (second x))
> 
> % xg
> GCL (GNU Common Lisp)  2.7.0 ANSI    Apr  1 2006 15:10:32
> >(load (compile-file "foo.lisp"))
> 
> >(f 'a)
> 
> Error in CDR [or a callee]: A is not of type LIST.
> 
> Fast links are on: do (si::use-fast-links nil) for debugging
> Broken at CONDITIONS::CLCS-UNIVERSAL-ERROR-HANDLER.  Type :H for Help.
>  1 (Continue) Return to top level.
> dbl:>>:q
> 
> Top level.
> >(g 'a)
> 
> Error in G [or a callee]: Control stack overflow.
> 
> Fast links are on: do (si::use-fast-links nil) for debugging
> Broken at CONDITIONS::CLCS-UNIVERSAL-ERROR-HANDLER.  Type :H for Help.
>  1 (Continue) Return to top level.
> dbl:>>:q
> 
> Top level.
> >(g 'a)
> Segmentation fault
> % 
> 
> 
> 
> 

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