Re: OS X Priorities for MCL

>
> Date: Fri, 31 Oct 2003 17:23:23 -0800
> From: Thomas Russ <tar@...>
> Subject: Re: OS X Priorities for MCL
>
> On Friday, October 31, 2003, at 02:26  PM, james anderson wrote:
>
> >> 2)  Better exception catching.
> > i wonder what you can expect in this regard.
> >
> > on one hand one might think 'well c can do it', but on the other hand,
> > although one can always attach mcl to gdb and have it trap your
> > addressing errors, when i've resorted to that, it's been because i've
> > done something unnatural like trash the stack. at which point i've
> > never been in a much better a position to interpret the state in gdb
> > than to interpret the normal stack dumps.
> >
> > ? what kind of support are you looking for?
>
> Well, I would like it not to crash.  That way I might have some chance
> to at least see which function blew up.  I realize that this may not be
> practical, but I have seen other lisps do this on Unix, so it may be
> possible...  I also realize that the place where something gets an
> address error may not be close to where the error was introduced, but
> when the entire environment exits, it's really tough to debug.
>

I think that there are a couple of alternate approaches to otherwise
unhandled exceptions that could be taken:

1) The kernel -could- treat some/all unhandled exceptions as errors.
It generally doesn't know whether certain types of exceptions (bad
memory references, for instance) are simple programming errors or
symptoms of stack or heap correuption, and in the latter cases
signalling a lisp error might cause more bad memory references or
other exceptions to follow.  It's not immediately clear why trying to
signal a lisp error and failing is a whole lot worse than simply
failing to handle the exception (and terminating the application/
entering GDB) is.

I think that if this policy were implemented and I got some sort
of unexpected memory-access error, I'd want to carefully save
what I was working on and quit the lisp session as soon as I
could, but seeing a lisp error message (hopefully) and being
able to see a lisp backtrace (hopefully) might make it easier
to prevvent the problem from recurring.

2) I think that if I got an unexpected exception - an attempt to
access an unmapped memory address, for instance - I'd ideally
want the lisp kernel to:

 a) tell me what it could about the exception: the address involved,
 whether it happened in lisp or foreign code, and some context information
 (some sort of backtrace, register information, maybe some sort of
 disassembly.)

 b) give me a few choices as to how to proceed: raise a lisp error,
 terminate the applicatiom, reset the current thread,  return (something)
 from the current lisp function, run some integrity checks on the stacks,
 heap, and global data structures and let me know if their obviously
 corrupt or if they appear intact, ...

(2) seems better than either the current policy (giving up completely
on an unhandled exception) or (1), but it depends on the kernel's
ability to somehow interact with the user.  As a TTY application,
OpenMCL's kernel ordinarily gets this ability for free (the kernel
just writes messages to standard output/error and reads from standard
input), and unhandled exceptions lead to a little builtin debugger
which offers -some- of the functionality that one might want.

In MCL's case, that's a little more complicated.  As a GUI application,
its standard input is connected to /dev/null and its standard output
and error are connected to the console logging facility (which can
be viewed with the OSX Console application.)  It wouldn't be too hard
to redirect these streams/file descriptors, but I'm not sure what
they shold be redirected to.

(People may remember that MCL on Classic MacOS had a "console" window,
that'd occasionally pop up and say things like "Hmm.  The current
thread's stack pointer seems to be somewhere in the middle of
Microsoft Word."  That was based on several brutal hacks that had
little chance of working in Carbon or OSX, but it did provide a means
for the kernel to interact with the user when using lisp-based I/O
facilities wasn't possible or advisable.)

I haven't yet thought of a good way to allow the kernel of a GUI
application to interact with the user (even if that interaction's
kind of terse and primitive.)  I suspect that this has been done
and/or thought about before; if anyone has any ideas or knows of
solutions, I'd appreciate hearing of them.

Gary Byers
gb@...