[Openmcl-devel] Re: [Bug-openmcl] lisp dies with "Mach error"

[Alan Ruttenberg]

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...

-Alan

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 
> there's
> no guarantee that the address of a TCR structure doesn't happen to 
> conflict
> with the (more-or-less random) value ("name") of an arbitrary Mach port
> object.
>
> 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 
> (and,
> 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, 
> semaphores,
> 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.