Re: [Gcl-devel] unhappy error handler

[Camm Maguire]

Greetings!

Peter Wood <address@hidden> writes:

> Hi
> 
> On Fri, Mar 04, 2005 at 05:41:52PM -0500, Camm Maguire wrote:
> > Greetings, and thanks for the report!  This was put in as a crude
> > first measure to remove error conditions arising from within the error
> > handler itself, usually in certain extreme circumstances such as
> > memory exhaustion, etc.  When this would happen, an endless loop of
> > identical and nested error invocations would be displayed immediately
> > before core dump.  If memory served, many of these instances pertained
> > to string manipulation, printing, and memory allocation.  Obviously,
> > the right way to do this is to put a recursion catcher in front of
> > each call, not inside the error handler itself, but I don't know how
> > to make the former work in a lisp system where various layers of user
> > code calling the error handler can freely pile on top of one another.
> > The other obvious option is to forsake general protection against
> > infinite error recursion, and attempt to track down each specific
> > instance where such a phenomenon can be created in the lowest level C
> > code, asymptotically at best approaching a solution.
> > 
> > Do you have any recommendations here?  I've even lost the previous bug
> > reports showing how to trigger the error recursion, so I don't know
> > where to begin to test.
> >
> 
> FWIW,
> 
> In some circumstances, you can prevent the segfault by not returning
> from the error-handler but instead throwing to a catch tag around the
> top-level loop.
> 
> >(setf foo (undef 'bar))
> 
> Error in SETF [or a callee]: The function UNDEF is undefined.
> 
> Fast links are on: do (use-fast-links nil) for debugging
> Broken at SETF.  Type :H for Help.
>  1 (Continue) Return to top level.
> dbl:>>(setf foo (undef 'bar))
> Universal error handler called recursively (:UNDEFINED-FUNCTION
>                                                   NIL SETF ""
>                                                   "The function ~S is 
> undefined.")
> 
> Top level.
> >
> 
> But really, this needs to get changed.  
> 
> Maybe 'extreme circumstances such as memory exhaustion' should be
> treated in a completely (or mostly) different way, than 'ordinary'
> error handling.
> 
> Perhaps there should be another error-handler for memory issues, so
> these two different types of errors don't get mixed up.  If a memory
> issue arises (triggered, eg, by infinite recursion) inside the
> error-handler, then maybe another handler should inform the user, and
> do whatever is necessary to continue sensibly, if at all possible (eg,
> abort the offending sequence of instructions, reset the stack, whatever).
> 
> There is a discussion here:
> 
> http://lists.gnu.org/archive/html/gcl-devel/2002-11/msg00029.html
> 
> which might be pertinent.  'Storage-conditions' should not get
> caught by ignore-errors, since they are not of type error.
> 

Thanks for the pointer.  I've reread this thread, and have a few
questions and comments on the way forward.

1) At the C level, your idea of macros passing the right keyword or
   symbol and changing the hash table in clcs_kcl_cond.lisp
   accordingly is right on.  I think I can implement this without too
   much pain,  I still have your old patch as a starter.

2) You note the serror functionality in the thread, to which Vadim has
   also separately referred, describing it as a pity to sacrifice for
   conditions, though a necessary one.  Are we free in ANSI to build
   conditions on top of serror as you appear to imply, presumably by
   making the condition type inherit the error type or some such?
   What exactly is it about serror that is worth preserving?  Perusal
   of the comments in gcl_serror.lsp indicates that some considerable
   thought was put into the efficiency and flexibility of the
   implementation -- not sure how this compares with clcs yet.

3) My plan is to effectively remove the recursive block except in
   cases of storage-condition, and to make sure we throw this at the
   right places.  Whether or not this requires a separate handler or
   code within the same handler would appear to be a somewhat
   arbitrary choice, no?

Take care,

> Regards,
> Peter
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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