[Openmcl-devel] The Cocoa bridge in OS X 10.3.9

[alex crain]

I commented out _GetCurrentEventQueue as per Gary's suggestion and
everything still works. It brings the test sample size up to 3, but my
cocoa app is pretty extensive.

:alex

On Apr 18, 2005, at 3:39 PM, Gary Byers wrote:

>
>
> On Mon, 18 Apr 2005, Tord Kallqvist Romstad wrote:
>
>> Hi!
>>
>> I tried to report the following problem on the OpenMCL mailing list a
>> couple of days ago, but for some reason my e-mail did not seem to
>> reach its destination.  The e-mail did not bounce back, but as far as
>> I can see it did not appear on the mailing list.  If my previous
>> message really did reach the list and I have just been blind, I
>> apologize for spamming.
>
> I don't remember seeing a previous message.
>
>>
>> My problem is the following:
>>
>> After upgrading to Mac OS X 10.3.9, the Cocoa bridge no longer seems
>> to work:
>>
>> Welcome to OpenMCL Version (Beta: Darwin) 0.14.3-050418!
>> ? (require "COCOA")
>> Unhandled exception 11 at 0x90000c18, context->regs at #xbfffe7d8
>> Read operation to unmapped address 0x0000000c
>>  In foreign code at address 0x90000c18
>>
>> This happens with the official 0.14.3 as well as the latest
>> bleeding-edge version. I have also tried reinstalling and recompiling
>> OpenMCL, but this did not solve the problem.
>>
>> Is there something wrong with my system, or does the Cocoa bridge
>> currently not work in 10.3.9?
>
> I just installed 10.3.9 and got the same crash, so I guess it's the
> latter.
>
> This seems to happen pretty early (long before all of the other things
> that -can- go wrong get a chance to do so ...).  There's a call to
> #_GetCurrentEventQueue in "ccl:examples;objc-runtime.lisp", right
> after the Cocoa library is loaded; that crashes attempting to use
> "zone_malloc" to allocate something, possibly because the zone in
> question is NULL and nothing has bothered to initialize it.  
> (Presumably,
> either the act of loading the libraries initialized the zone in
> previous releases, or #_GetCurrentEventQueue didn't use #_zone_malloc,
> or some similar combination of factors allowed this to work.)
>
> Commenting out the call to #_GetCurrentEventQueue seems to fix things,
> which certainly raises the question of what it's doing there in the
> first place ...  As I recall, it was necessary to call
> #_GetCurrentEventQueue early and on the main thread to prevent some
> Carbon confusion (the application event loop would hang, because it
> was listening on the wrong Carbon event queue, and IIRC -that- happened
> as a side-effect of something that happened while the bridge was
> initializing itself.)  I have a further (dim) recollection that 
> whatever
> caused the Carbon confusion was/is timing-sensitive: someone else was
> experiencing the problem and I wasn't, and all other things appeared
> to be equal.
>
> So:
>   - it doesn't seem possible to call #_GetCurrentEventQueue early
>     under 10.3.9.  (The Cocoa demo fails much later in the process -
>     and for other reasons - on later OS releases.)
>   - from a small sample size (e.g., me trying it twice, so far),
>     it doesn't seem necessary to call #_GetCurrentEventQueue "early,
>     and from the initial thread" in order to keep the Carbon Event
>     transport mechanism from becoming confused
>   - it is unknown (so far) whether it's still necessary to do something
>     to avoid this confusion on other OS releases.
>
> Something in the back of my mind says that the original problem had
> something to do with font initialization - that there was or is code
> that did something like:
>
> (defvar *font-to-use-somewhere* (sent (find-class 'ns:ns-font) 
> :some-init-message ....))
>
> and sending that message from the (original) listener thread before
> the event loop had started in the initial thread caused some Carbon
> (mis-)initialization to occur.  Neither the main 0.14.3 version nor 
> today's
> bleeding-edge version seems to trigger the problem under OSX 10.3.9,
> and commenting out the call to #_GetCurrentEventQueue seems to work
> reliably.  I don't know about earlier OSX versions (yet).
>
>>
>> --
>> Tord Romstad
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>