[Openmcl-devel] Is this an OpenMCL 'problem'?
Gary Byers
gb at clozure.com
Fri Apr 7 00:42:02 PDT 2006
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
>
>
More information about the Openmcl-devel
mailing list