[Openmcl-devel] CCL apps likely to crash on OS X Mountain Lion when including NSScrollView
Gary Byers
gb at clozure.com
Fri Apr 26 13:47:12 PDT 2013
Your button's action method
- creates and initializes an instance of NSScrollView
- initializes it again via #/initWithFrame:
- forgets about it (never installs it in the view hierarchy of any window,
etc.)
and you often get a crash where something's complaining about some private
attribute of the scroll view not being initialized properly.
Does this work better when you do it in ObjC ?
Someone reading the subject of your message might reasonably conclude
that there's some problem using NSScrollViews in CCL. That'll be news
to everyone and everything that uses them.
Instead of:
(objc:defmethod (#/nsButtonAction :void) ((self ns:ns-button))
(let ((scroll-view (make-instance 'ns:ns-scroll-view)))
(ns:with-ns-rect (Frame 0 0 100 100)
(#/initWithFrame: scroll-view Frame))))
you could do
;;; This is similar to what you do when creating instances of other NSView classes
(objc:defmethod (#/nsButtonAction :void) ((self ns:ns-button))
(let ((scroll-view (#/alloc ns:ns-scroll-view)))
(ns:with-ns-rect (Frame 0 0 100 100)
(#/initWithFrame: scroll-view Frame))))
or just let MAKE-INSTANCE do the work:
(objc:defmethod (#/nsButtonAction :void) ((self ns:ns-button))
(ns:with-ns-rect (Frame 0 0 100 100)
(make-instance 'ns:ns-scroll-view :with-frame Frame)))
or ...
I have no idea whether fixing that will cause your crashes to go away; I don't
know whether Mountain Lion likes dealing with disembodied NSScrollViews (as
long as they're properly initialized) or not.
On Thu, 25 Apr 2013, Alexander Repenning wrote:
> We have a very strange thing going on with NSScrollView on Mountain Lion. It is not clear if CCL is directly or indirectly causing this but the bottom line is that any CCL/Cocoa based application including NSScrollViews (they are pretty handy) trying to run on Mountain Lion has a good chance of crashing. Took us a while to narrow some mysterious crashes down to this. To make things worse, this only seems to happen on about 50% of the machines we tested on.
>
> This is what happens. If you have a Mountain Lion machine with the following system preference: "Show scroll bars" to "Automatically based on mouse or trackpad" In this mode, any NSScrollView will only show scroll handles when the mouse is hovering over it. This behavior seems to be achieved, not surprisingly, through a timer. On SOME machines the moment you create an NSScrollView and set it frame this timer gets started and if about ~1 second later, if that NSScrollView is not ready for some update all hell breaks loose. On the trace below you can see:
>
> a call to [_NSScrollerStyleRecommender scrollerStyleRecommendationUpdateTimerFired:] resulting in a call to [NSScrollerImpPair _updateAllScrollerImpPairsForNewRecommendedScrollerStyle:]
>
> Of course these methods are not documented. A search and query on Stack overflow did not result in anything. Regular Xcode apps with NSScrollViews do not appear to exhibit this problem.
>
> To reproduce you can run the code below. A window with a button will show up. Press the button. With 50% chance the crash will happen. Observations:
>
> - no correlation to version of CCL (1.9, 32bit/64bit)
> - no correlation to version of Mountain Lion 10.8.1, 10.8.2, 10.8.3. have all been observed to crash
> - the crash either happens EVERY TIME you press the button or NEVER
> - the crash never happens in CCL with a Listener present
>
> The test code below just makes an instance of NSScrollView and calls initWithFrame. No view actually shows up. This is not super meaningful but has a high chance of causing the problem.
>
>
> Any idea what could cause this or better how how to stop this would be super helpful. Test source, link to test app and stack trace are below. The main question is why, on some machines, this timer would be started and how this could be correlated in CCL to have listener window, or not. Any ideas would be appreciated.
>
> best, Alex
>
>
>
> __________ Scroll-crash.lisp ___________
>
>
> ;; eval file in CCL and then launch the app created
>
> (in-package :gui)
>
> (defun SHOW-TEST-WINDOW ()
> (let ((window (make-instance ns:ns-window
> :with-content-rect (ns:make-ns-rect 100 800 300 50)
> :style-mask
> (logior #$NSTitledWindowMask
> #$NSClosableWindowMask
> #$NSResizableWindowMask
> #$NSMiniaturizableWindowMask)
> :backing #$NSBackingStoreBuffered
> :defer t))
> (content-view (#/initWithFrame: (#/alloc ns:ns-view) (ns:make-ns-rect 0 0 300 50)))
> (button (#/initWithFrame: (#/alloc ns:ns-button) (ns:make-ns-rect 0 0 300 50))))
> (#/setAction: button (objc::@selector #/nsButtonAction))
> (#/setTitle: button (ccl::%make-nsstring "Make NSScrollView"))
> (#/setContentView: window content-view)
> (#/addSubview: content-view button)
> (#/orderFront: window nil)))
>
> (objc:defmethod (#/nsButtonAction :void) ((self ns:ns-button))
> (let ((scroll-view (make-instance 'ns:ns-scroll-view)))
> (ns:with-ns-rect (Frame 0 0 100 100)
> (#/initWithFrame: scroll-view Frame))))
>
> (objc:defmethod (#/applicationDidFinishLaunching: :void)
> ((self lisp-application-delegate) notification)
> (declare (ignore notification))
> (show-test-window))
>
> (objc:defmethod (#/applicationShouldOpenUntitledFile: #>BOOL)
> ((self lisp-application-delegate) app)
> ;; DO NOT SHOW LISTENR!
> (declare (ignore app))
> nil)
>
> (progn
> (require "build-application")
> (ccl::build-application :name "Scroll-CRASH"
> :directory (format nil "~A/Desktop/" (user-homedir-pathname))))
>
>
>
>
>
>
> _________ end ______________
>
>
> For your replication convenience here is a ready to launch test app in CCL (~80MB): http://www.cs.colorado.edu/~ralex/temp/Scroll-CRASH.app
>
>
> more info:
>
>
>
>
> ? The bug was initially showing up in AgentCubes and would cause a crash every time we brought up a window that contains an NSScrollView
> ? We tested it on 4 different mountain lion machines and the bug would occur on all of them when the "Automatically based on mouse or trackpad" preference was set
> ? We have tried to reproduce the bug with just CCL but it never seems to occur inside of the CCL application
> ? We have found that we need to create an application which has no listener in order to reproduce the error (this is done in the test app)
> ? We eventually narrowed the bug down to a call to initWithFrame: if this is called on an NSScrollView, inside of an application which has no listener then the crash will happen if the preference is set
> ? We tried to run many other tests but most of them were related to our cocoa wrapper which turned out to be a dead end when we discovered the bug could be reproduce with only the cocoa class
>
> Here is the stack trace:
>
> 4/24/13 3:10:57.761 PM Scroll-CRASH[1010]: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: scrollerImpPair == SCROLLER_IMP_PAIR'
> *** Call stack at first throw:
> (
> 0 CoreFoundation 0x99cbee9b __raiseError + 219
> 1 libobjc.A.dylib 0x90a6552e objc_exception_throw + 230
> 2 CoreFoundation 0x99c1e6a8 +[NSException raise:format:arguments:] + 136
> 3 Foundation 0x93dfb814 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 116
> 4 AppKit 0x977cd7ab -[NSScrollView(NSPrivate) scrollerImpPair:updateScrollerStyleForNewRecommendedScrollerStyle:] + 150
> 5 AppKit 0x977cd6a5 +[NSScrollerImpPair _updateAllScrollerImpPairsForNewRecommendedScrollerStyle:] + 406
> 6 AppKit 0x977cd4ff +[NSScrollerImpPair _scrollerStyleRecommendationChanged:] + 159
> 7 Foundation 0x93e52152 __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 + 49
> 8 CoreFoundation 0x99c80861 ___CFXNotificationPost_block_invoke_0 + 257
> 9 CoreFoundation 0x99bcbe9a _CFXNotificationPost + 2794
> 10 Foundation 0x93e3ac88 -[NSNotificationCenter postNotificationName:object:userInfo:] + 92
> 11 AppKit 0x977cd3f5 -[_NSScrollerStyleRecommender setRecommendedScrollerStyleAndNotify:] + 248
> 12 AppKit 0x977cd2e3 __75-[_NSScrollerStyleRecommender scrollerStyleRecommendationUpdateTimerFired:]_block_invoke_0 + 43
> 13 AppKit 0x97eff42f __block_global_0 + 32
> 14 libdispatch.dylib 0x98f10f8f _dispatch_call_block_and_release + 15
> 15 libdispatch.dylib 0x98f0cc82 _dispatch_client_callout + 46
> 16 libdispatch.dylib 0x98f122e3 _dispatch_main_queue_callback_4CF + 223
> 17 CoreFoundation 0x99bbac39 __CFRunLoopRun + 1961
> 18 CoreFoundation 0x99bba02a CFRunLoopRunSpecific + 378
> 19 CoreFoundation 0x99bb9e9b CFRunLoopRunInMode + 123
> 20 HIToolbox 0x91e16f5a RunCurrentEventLoopInMode + 242
> 21 HIToolbox 0x91e16cc9 ReceiveNextEventCommon + 374
> 22 HIToolbox 0x91e16b44 BlockUntilNextEventMatchingListInMode + 88
> 23 AppKit 0x976e99aa _DPSNextEvent + 724
> 24 AppKit 0x976e91dc -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 119
> 25 AppKit 0x976df63c -[NSApplication run] + 855
> 26 Scroll-CRASH 0x000198f5 SPffcall + 85
> 27 ??? 0x003cbfb0 0x0 + 3981232
>
>
> 28 ??? 0x003cbfb0 0x0 + 3981232
> 29 Scroll-CRASH 0x00019f51 func_start + 94
> 30 Scroll-CRASH 0x0001c75e main + 910
> 31 Scroll-CRASH 0x0002fa51 _start + 208
> 32 Scroll-CRASH 0x0002f980 start + 40
> 33 ??? 0x00000002 0x0 + 2
>
>
> Prof. Alexander Repenning
>
> University of Colorado
> Computer Science Department
> Boulder, CO 80309-430
>
> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>
More information about the Openmcl-devel
mailing list