[Openmcl-devel] The Cocoa bridge in OS X 10.3.9
alexcrain at mail.widgetworks.com
Mon Apr 18 20:10:09 UTC 2005
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.
On Apr 18, 2005, at 3:39 PM, Gary Byers wrote:
> On Mon, 18 Apr 2005, Tord Kallqvist Romstad wrote:
>> 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
> 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.
> 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
> 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.
> - 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
> 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
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel