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

[Gary Byers]

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