[Openmcl-devel] Re: [Bug-openmcl] NSViewHierarchyLock Assertion failure

[Gary Byers]

On Fri, 14 May 2004, Raffael Cavallaro wrote:

>
> > The bad news is that the drawRect: method - used
> > to automatically update invalid view rectangles from the main thread -
> > is a no-op, so portions of the view that're exposed don't get redrawn
> > until the next animation cycle.  Fixing this is left as an excersise
> > (hint: don't allow the view's NUMSIDES instance variable to change
> > unless the view is locked for drawing.)
>
> This exercise is my next openmcl task.

Well, if you'd prefer doing an exercise to an "excercise" ...

>
> Thanks again.
>
> Ralph
>
>
> P.S.
> What follows might be considered cruel and unusual punishment, but I
> thought you might be interested as it is an outright hang.
> Really beating on it by trying to create 20 animation windows while
> iTunes is playing an mp3  can cause OpenMCL to hang outright
> (Application Not Responding) with the console error:
>
> 2004-05-14 14:11:57.371 dppccl[2473] *** Assertion failure in
> -[NSViewHierarchyLock unlockTopMostReader],
> AppKit.subproj/NSViewHierarchyLock.m:428

That seems to be the same assertion failure that Sebastian Nozzi first
reported.  He said that it seemed to have disappeared for him in 0.14.2,
but perhaps (if it's very timing-sensitive) he's just having better luck.
If this were a little easier to reproduce it might still be hard to debug;
as it is, I'm not sure how to go about doing so.

One difference between 0.14.2 and earlier versions of the objc-runtime
glue is that an NSThread is created (and allowed to exit) before lisp
does much of anything else with Cocoa/ObjC.  This is supposed to help
convince Cocoa that the application really is multi-threaded (every
other layer - POSIX, CoreFoundation, Carbon - seems able to figure
that out on its own.)

I don't know whether this change really makes this particular
assertion failure less likely; if we had the source to
NSViewHierarchyLock.m we might know -what- assertion had been made
and failed; as it is, we'll just have to guess.

>
> Sometimes when I do this torture test, rather than hanging with the
> above console error, OpenMCL will just enter a break loop:
>
>  > Error in process Listener(5): Objective-C runtime exception:
>  >                               Error (268435471) creating CGSWindow
>  > While executing: CCL::CHECK-NS-EXCEPTION
>

I tend to believe that this may be a real runtime error: if you ask
the window server to create and repeatedly draw a number of largish
windows in fairly rapid succession, it might occasionally say "not
now, I'm busy" (or whatever 268455471 means.)

If an unhandled ObjC exception occurs in a listener thread, it'll
just signal a lisp error; if it happens in the Cocoa event thread,
that thread will just log a message and go get the next event.  I don't
know that I'd argue that either of these behaviors is optimal, but
popping up a sleek GUI debugger (when the window system's just told
you that it's overloaded) might not be optimal, either.