[Openmcl-devel] Is this an OpenMCL 'problem'?

[Gary Byers]

On Fri, 7 Apr 2006, Phil wrote:

> I had created a method via define-objc-method for an NSTableView and
> then proceeded to return the wrong data type (i.e. it was declared as
> returning an id and had mistakenly returned an int.)  Not a big deal to
> fix but I was surprised to see Slime hang when the method was called.
> When I re-ran the offending code directly in an OpenMCL session, I
> discovered why: MCL had dropped into the kernel debugger which Slime
> apparently doesn't know how to deal with.
>
> So I'm just wondering if this is the intended/desired behavior (i.e.
> dropping into a kernel debugger for this type of problem) or should
> OpenMCL catch this and drop to the normal debugger?

It's intended that if you try to reference unmapped memory you succeed
in referencing unmapped memory.  (This happens even if -you're- not 
trying to reference unmapped memory, but the code that you write is ...)

For example:

? (defun fast-unsafe-cdr (x)
     "not necessarily realistic, but maybe easy to understand"
     (declare (list x) (optimize (speed 3) (safety 0)))
     (cdr x))
FAST-UNSAFE-CDR
? (fast-unsafe-cdr 1)
==> splat.

Once that happens and the code which handle the resulting exception
concludes that it has no idea of how to proceed, there are a few
fairly reasonable courses of action, and there seem to be some
tradeoffs involved:

1) This could be signaled as a lisp error, something like:

Error: illegal memory reference to address <whatever>
        while executing FAST-UNSAFE-CDR
1 >

In a case like the example above, this seems like a reasonable way
to proceed: it's a silly mistake and (so far) there have been no
other consequences of that mistake.

In general, I'm not sure that treating an unexpected illegal memory
reference as a lisp error (not too unlike what'd have happened if
that had been CDR instead of FAST-UNSAFE-CDR) is a good idea.  The
memory reference might have been the final symptom of a whole chain
of more subtle problems, and if it's possible to signal a lisp error
in that dynamic environment it may not be a good idea to do so.  (If
the illegal memory reference is indeed at the end of a chain of other
problems, unconditionally calling into lisp may or may not make it
easier to find the head of the chain.)

2) An unhandled low-level exception (bad memory access) could just
invoke the kernel debugger.  This is indeed what happens; the kernel
debugger provides a little bit of support for poking around and -very-
limited ability to recover from the situation

Unhandled exception 11 at 0x1047784c4, context->regs at #xf0235290
Read operation to unmapped address 0x4
  While executing: #<Function FAST-UNSAFE-CDR #x00000001047784ec>
? for help
[456] OpenMCL kernel debugger: a
[456] OpenMCL kernel debugger: x
1
?

In that particular case, using "a" to skip over the current instruction
(the one that was trying to access the contents of memory location 4)
"worked"; the return value was meaningless, but no harm was done and
we're back at a listener prompt.  If this wasn't such a simple example,
any sort of "recovery" at that level probably would have involved GDB.

I don't think that either of these approaches is entirely optimal.  I
think that I'd ultimately favor a mixture of the two: dropping into
the kernel debugger first, but providing an option to attempt to recover
by treating the exception as a lisp error.

>
> Here's the error if it matters:
> Unhandled exception 11 at 0x8cc5a58, context->regs at #xf0a9c3a8

> Read operation to unmapped address 0x2

>  While executing: #<Function -[BrowseTableView
> tableView:objectValueForTableColumn:row:] #x08cc5b26>
>
> A related question: I'm still having problems getting my code running
> and was wondering if anyone has a good (relatively simple) example of
> using an NSTableView in OpenMCL?  I've been looking at the
> cocoa-inspector code but am still not understanding what is missing in
> my code.

ccl:examples;cocoa-backtrace.lisp uses NSOutlineViews and actually
doesn't do anything too complicated with them, but the rest of it
(dealing with "stack frame objects") is pretty obscure ...


>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>