gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: random segmentation violations


From: Camm Maguire
Subject: [Gcl-devel] Re: random segmentation violations
Date: 09 Apr 2006 20:37:23 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Robert Boyer <address@hidden> writes:

> Are you interested in interpreted calls of system functions
> that cause GCL 2.7.0 to say something like:
> 
>    Caught fatal error [memory may be damaged]?
> 

Yes!  These are all mistakes.  They are basically missing check-types
at the top of the functions.  System functions at present are compiled
at safety 1, which means "check arguments".  Errors are automatically
triggered if the call signature does not match the function signature,
but type checking must be done explicitly.  The alternative is to
compile at safety 2, which disables certain inlining, making
essentially all calls within the function check arguments too,
e.g. car, cdr ....  It appears that the best way to pass Paul's tests
on system functions without sacrificing performance is the above
method at safety 1.

> Some examples:
> 
>    (WRITE-LINE 0 0)
>    (WRITE-STRING 0 0)
>    (ETYPECASE '(1 2 3) 4)
>    (CTYPECASE 1 2 3 4 5)
> 
> Let me know if you have any interest in more.  I'm merely
> feeding to a random, external, fboundp symbol of package
> COMMON-LISP some random objects in the GCL 2.7.0 image.
> 
> I am not smart enough to know for sure whether "memory may
> be damaged" is "ANSI wrong".
> 
> As a user, I could tell you what I think, but as a
> government employee I better not use such words in email.
> 
> I don't mind such "memory may be damaged" messages when I
> run something compiled at SAFETY 0.  There I get what I
> deserve and am taking my chances.
> 
> However, when debugging with interpreted code, I would
> prefer to have such errors caught more gracefully than
> "memory maybe damaged".
> 
> It could well be that I am asking for too much.  It may be
> that "memory may be damaged" is actually what we really
> want, after several decades of consideration, so that, for
> example, at SAFETY 0 one can get better performance.
> 
> Here's a somewhat encouraging passage from the ANSI:
> 
>    The informal intent is that the programmer can rely on a
>    call to be safe, even when system code is involved, if
>    all reasonable steps have been taken to ensure that the
>    call is safe.  For example, if a programmer calls mapcar
>    from safe code and supplies a function that was compiled
>    as safe, the implementation is required to ensure that
>    mapcar makes a safe call as well.
> 
> But just what are "reasonable steps"?  The ANSI does not
> spell that out as far as I can tell.  So, what is the
> possible penalty for passing an operation an argument of the
> wrong type?
> 
>    Except as explicitly specified otherwise, the
>    consequences are undefined (i.e., it says elsewhere, may
>    range from harmless to fatal) if these type restrictions
>    are violated.
> 
> So, for example, in the case of 'car', since an error
> "should" be signalled, the form (car 3) typed to the very
> top-level read-eval-print-loop at SAFETY 3 must cause an
> error.  However, the form (* 'a) only "might" signal an
> error, and so could in principle delete all your files, even
> at SAFETY 3.  Or even do the dread:  (push-the-button)!
> 
> Who knows?  Not me.
> 
> Bob
> 
> 
> 

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]