[Openmcl-devel] Re: [Bug-openmcl] lisp dies with "Mach error"
alanr-l at mumble.net
Tue May 3 04:58:17 UTC 2005
This is indeed in 0.14.3.
It's happened that once only. I wasn't creating lots of threads, though
there were some that I created, as well as the usual slime threads.
Seems like the chances are higher than O(1/2^32) if it's happened to
both of us...
On May 1, 2005, at 9:06 PM, Gary Byers wrote:
> On Wed, 27 Apr 2005, Gary Byers wrote:
>> On Wed, 27 Apr 2005, Alan Ruttenberg wrote:
>>> Haven't seen this one before...
>>> No backtrace. No kernel debugger.
>>> While running slime. I think I was inspecting something.
>>> If I can make this repeat I will send further information.
>>> Running on PBG4, 1.2GHz, os 10.3.8, 2G Ram.
>>> Fatal error: Mach error
>>> Mach error while naming exception_port : 13
>>> Process inferior-lisp exited abnormally with code 255
>> I've seen that (in situations where lots of threads had been created
>> and died); I had -thought- that there was code in 0.14.3 that kept it
>> from happening. Is this 0.14.3, or an earlier version ?
> It's not clear whether this was happening in 0.14.3 or earlier, but
> no guarantee that the address of a TCR structure doesn't happen to
> with the (more-or-less random) value ("name") of an arbitrary Mach port
> We can ensure that there's no conflict by trying to create a Mach port
> whose "name" matches the TCR's address whenever a TCR is allocated
> if there happens to be a random conflict, keep allocating TCRs until
> we luck out.)
> The odds of a random address conflicting with a port name are probably
> around N/2^32, where N is the number of Mach ports (threads,
> etc.) that have been incidentally created. I think that there's some
> Apple debugging tool that will show this information (possibly GDB),
> and I think that N is usually pretty small.
More information about the Openmcl-devel