[Openmcl-devel] Clozure CL 1.3-RC1 available
Gary Byers
gb at clozure.com
Tue Mar 10 02:23:27 PDT 2009
<http://support.apple.com/kb/HT1455?viewlocale=en_US> describes how to
boot a Mac in "safe mode" (short version: hold down the shift key when
you hear the chime while booting), and
<http://support.apple.com/kb/HT1564?viewlocale=en_US> describes some
of what happens when a Mac is booted in safe mode (among other things,
only a limited/minimal set of kernel extensions is loaded.) Does
booting in safe mode cause the problem to go away ?
If so, that would tell us that some kext causes the problem; it
wouldn't tell us exactly which one. (Long-time Mac users may
remember "INIT hell", where it was possible to spend way too much
time trying to figure out which combination of otherwise useful
extensions was causing the menubar to appear on the bottom of
the screen. In comparison to the tools that were developed
to try to deal with those problems. "safe mode" seems kind
of primitive, but since problems like that are harder to create
in the first place, that may be a good thing.
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.) That's almost cetainly a
very low-level software issue: what the hardware does in response to
the attempt to execute an unimplmented instruction is (excruciatingly)
well-defined, but what the OS does in order to report that situation
to the application and offer it a chance to handle the exception is up
to the OS. (Some of the things that Tiger does are slightly different
from what Leopard does; it's not clear to me why an OS would make a
change like that, since if not user-level code is using the
functionality it doesn't matter how some cases classified and if user
code is using the functionality a change breaks that code.) Whether
OSes should or should not change the details of how very-low-level
machine exceptions are reported in a slightly-higher-level way is
another issue, but it seems fairly clear to me that third-party
software (kexts) should not do this.
If some third-party kext is changing this (fairly obscure) detail
of OS behavior, I doubt if too many applications would notice. (CCL
would, some other Lisp implementations might be sensitive to the
same or similar details; after that, it's probably a short list.)
If I had to guess (and I do ...), if this does turn out to be
a kext issue, the Parallels kext(s) would be the most liely suspect(s)
(if only because they're much more likely to want to deal with things
like this tnan a decice driver would. I'd be surprised if that change
was intentional and I'd consider it to be a bug, but if that's all
true it's probably not a bug that affects many applications.
I suppose that the first step is to just see if booting in safe mode
implicates a kext ...
On Mon, 9 Mar 2009, John Stoneham wrote:
>
>> I was able to upgrade the copy of OSX server to 10.4.11 (cable modems
>> are wonderful things ...). Both the trunk and 1.3-rc1 versions of
>> the lisp seem to behave as expected in that environment.
>
> I just updated to the latest trunk and I still get my same (bizarre) behavior. BTW, I'm not sure if I mentioned this before, but I dual-boot Tiger and Leopard on this machine. I get the same behavior on both Tiger and Leopard, so I doubt the "Server" edition has anything to do with it. I usually boot into Tiger, so it's possible I only mentioned Tiger in this context, but I have tried it under Leopard on this same machine, and it still has the same problem.
>
>>
>> I'm curious about what's going on here and will try to look at it
>> as time permits, but right now time doesn't permit a lot.
>
> I do have Parallels installed (on both the Tiger and Leopard partitions), but I only run it when I need to (not very often). However, there are some Parallels kexts that are loaded during startup, so maybe this is what you were talking about. I don't know, though. I don't seem to have similar problems with any other software, so it's very confusing to me.
>
> Thanks for looking into this anyway. It would be nice to hear from one other person with a 32-bit machine as to whether it works for them or not. Who knows, I may just have a fluke processor that's borking on some instruction it shouldn't. *shrug*
>
>
>
>
>
>
More information about the Openmcl-devel
mailing list