[Openmcl-devel] Clozure CL 1.3-RC1 available
gb at clozure.com
Thu Mar 12 01:31:44 UTC 2009
On Wed, 11 Mar 2009, John Stoneham wrote:
>> Does booting in safe mode cause the problem to go away ?
> Unfortunately, no. I did notice that my iStat Menu meters (cpu, temp
> guages, etc) still loaded in safe mode, though I'm not sure why
> since I thought that was the point of safe mode. I tried
> uninstalling iStat and rebooting again, but it didn't help with the
> ccl exceptions. >
I think that the kextstat program will display information about loaded
kexts. (As will System Profiler, under Software->Extensions.)
I'm not sure how Safe Mode decides what's safe and what isn't.
> Out of curiosity I started Parallels and installed the Windows
> version of ccl. It ran fine. That may not mean anything at all
> though. Running ccl that way isn't really an option for me either,
> because I'm interested in the cocoa stuff. >
The problem seems to involve how hardware exceptions (executing a particular
illegal instruction) are reported to Mach exception handlers. I'm pretty
sure that the same exception will get from the hardware to Windows in
a VM without going through Mach.
>> Whatever's causing it, the problem seems to be that a Mach exception
>> handler receives different information on your machine than CCL
>> expects when a thread executes a kind of illegal instruction (that's
>> intended to cause an exception to occur.)
> I think there's more going on than that, since I doubt that (QUIT)
> is supposed to trigger an illegal instruction. >
You shouldn't doubt that ... (!)
QUIT uses PROCESS-INTERRUPT (threads tell each other to shut down),
and that may indeed cause an illegal instruction to be (intentionally)
execcuted. (If a thread gets an interrupt while in foreign code, we
basically defer the handling of the interrupt until the thread returns
to lisp, and we use an illegal instruction to force the thread to take
the deferred interrupt when it's safe to do so:)
^C also uses PROCESS-INTERRUPT; if the listener's just sitting at a
prompt (actually, blocked reading from standard input) and you type a
^C, you'll probably see the same confused response that you see on
This much seems pretty clear to me; what's unclear is why things
behave differently for you once that illegal instruction is executed.
> Anyway, someone else reported that they were not having any problems
> on their 32-bit intel Mac, so maybe there is just something screwy
> with my hardware for some reason. Rather than waste development time
> on this, you might want to wait until you hear from someone else
> that has a similar problem, since it may just be a fluke on my end.
Like I said, I really think that this is a software problem.
You're right, though: until we get more data or some way to reproduce
the problem, there isn't much that I can do but guess and maybe get
lucky and guess right one of these days.
More information about the Openmcl-devel