Re: [Gcl-devel] Additional structure tests added

[Peter Wood]

Hi, Camm
On Fri, Jan 03, 2003 at 04:48:01PM -0500, Camm Maguire wrote:
> Greetings!  Hi Peter!  Just following up on a few other thoughts you
> posted: 
> 
> Peter Wood <address@hidden> writes:
> 
> > Hi Paul.
> > 
> > On my version of GCL, a memory violation is a 'storage-condition', not
> > an error, so the rt handler is not interfering with
> > our_signal_handler(), and the process does not abort (I take this as
> > another confirmation that my error condition patches were the right
> > thing).
> > 
> 
> Could you elaborate on the conflict that leads to the abort here?  I
> assume what we should have seen with the just-fixed segfault is a
> '(...) not a struct' or some such?  Or is the segfault the intended
> behavior when the code is compiled with no safety options?
> 

I was also getting a segfault, but my process wasn't getting aborted.

The important thing is the _type_ of the error which gets signalled.
In ansi CL, an error of the type in question here is a
storage-condition or a subtype (impl-dependent) of storage-condition
_NOT_ a subtype of 'error'.  So it doesn't get handled by handlers
established by ignore-errors, handler-bind or handler-case, unless you
specifically program for it to be handled by specifying (for ex,
(handler-case (xyz) (storage-condition (c) (do-something-with c).  In
the situation which gave rise to the abort, the tests are correctly
handling errors (after all that's what they are intended to do) but
GCL inappropriately classifies the segfault as an error not as a
storage-condition.  The net result is, in effect, that GCL is
pretending the segfault didn't happen, and attempting to continue in
the same frame stack (if thats what it's called).

This is what the hyperspec says in the function description of error:
" If the condition is not handled, (invoke-debugger condition) is
done. As a consequence of calling invoke-debugger, error cannot
directly return; the only exit from error can come by non-local
transfer of control in a handler or by use of an interactive debugging
command. "

The code for signalling the error is in main.c and looks like this:

void
error(char *s)
{
        if (catch_fatal>0 && interrupt_enable )
            {catch_fatal = -1;
           if (sgc_enabled)
             { sgc_quit();}
           if (sgc_enabled==0)
             { install_segmentation_catcher() ;}
           Icall_error_handler(sKsimple_storage_condition,
                               make_simple_string("Caught fatal error: memory 
may be damaged."),
                               0);}
           /*FEerror("Caught fatal error [memory may be damaged]",0);*/ 
        printf("\nUnrecoverable error: %s.\n", s);
        fflush(stdout);
#ifdef UNIX
        abort();
#endif

/*-- the commented line is, as you know, the old classification.*/
> 
> > The culprit is find-class, not typep (my #'typep does take class
> > arguments, and most of the struct tests are passing).  For some
> > reason, the defstruct form for struct-test-22 is not working properly
> > with PCL's clos system.  I am in the process of trying to figure out
> > what is going on.
> > 
> 
> I think you're referring to my bypassing the pcl type classes in typep
> and subtypep.  I was meaning to revisit this to avoid all the hand
> subtypes I entered previously to pass Paul's tests.  Anyway, I think I
> know how to improve this, but would like to know what you've done
> here.

No, I wasn't referring to anything you've done. 

_experimentally_, I have made coerce, typep, and subtypep generic
functions, using #'pcl::make-specializable (which is broken, but easy
to fix).  It looks something like this (I have changed typep to take
the optional env arg):

(setf (symbol-function 'specialized-typep) (symbol-function 'typep))

(pcl::make-specializable 'specialized-typep :arglist '(obj type &optional (env 
nil)))

(setf (symbol-function 'typep) (symbol-function 'specialized-typep))

(defmethod typep ((obj t) (type built-in-class) &optional (env nil))
    (when (eq (class-of obj)
            type)
        obj))

(defmethod typep ((obj t) (type standard-class) &optional (env nil))
    (when (eq (class-of obj)
            type)
        obj))

(defmethod typep ((obj t) (type structure-class) &optional (env nil))
      (when (eq (class-of obj)
            type)
        obj))

(fmakunbound 'specialized-typep)
(unintern 'specialized-typep))

Its a _lot_ easier than fixing things on the c side, and has the
advantage of reusing the current c code.  However, it obviously has
performance implications so you might not want to use it. ( Ideally, I
would like to write a (full) clos in c, but its a major, major project -
beyond my current skills.).

Regards,
Peter

(ps. [OT] if you want to, you can drop specific-error and
specific-continuable-error and call si:universal-error-handler
directly in (:system-p t) code that needs to signal a specific type of
error.)