Re: [Gcl-devel] unhappy error handler

[Peter Wood]

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.

Regards,
Peter