• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
NSWindowController, bindings and Garbage Collection
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NSWindowController, bindings and Garbage Collection


  • Subject: NSWindowController, bindings and Garbage Collection
  • From: Nikita Zhuk <email@hidden>
  • Date: Tue, 24 Feb 2009 22:22:25 +0200

I'm running a Cocoa application with Garbage Collection enabled, linking against 10.5 SDK. My application has a NSWindowController subclass which instantiates a window from a nib file (- [NSWindowController initWithWindowNibName:]) and acts as the File's owner of that nib. The window in the nib has several controls with values bound to properties of a model object, which is accessible through the File's owner. The model object assumes that all method calls made to retrieve its values are made in the main thread - it has assertions which verify that this is the case.

Under manually managed memory this works as expected - all bound values are fetched from the model object on the main thread and file's owner is deallocated after the window is closed. When the application is compiled and run with GC, file's owner is collected (finalize is run), but after a while NSBinder instance accesses my model class from a subthread, causing the "main thread only" assertion of my model class to fail with the following stack trace:

#2 0x0000a3aa in -[MyModelObject mainThreadOnlyMethod:] at MyModelObject.m:123
#3 0x936ebf6b in _NSGetUsingKeyValueGetter
#4 0x936eba07 in -[NSObject(NSKeyValueCoding) valueForKey:]
#5 0x9376aa01 in -[NSKeyValueNestedProperty object:didRemoveObservance:]
#6 0x93749c43 in -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:]
#7 0x937499e4 in -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:]
#8 0x9376aa21 in -[NSKeyValueNestedProperty object:didRemoveObservance:]
#9 0x93749c43 in -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:]
#10 0x937499e4 in -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:]
#11 0x93b3f690 in -[NSBinder _updateObservingRegistration:]
#12 0x93b85d0f in -[NSBinder releaseConnectionWithSynchronizePeerBinders:]
#13 0x93d288c8 in -[NSBinder finalize]
#14 0x933546b6 in finalizeOneObject
#15 0x91488dab in foreach_block_do
#16 0x9335487b in batchFinalize
#17 0x93354b42 in batchFinalizeOnTwoThreads
#18 0x91489f0e in auto_collect_internal
#19 0x9148ab8f in auto_collection_thread
#20 0x9559a095 in _pthread_start
#21 0x95599f52 in thread_start


There have been a similar problem reported earlier when using Core Data, bindings and GC [1]. The problem seem to be the same. How this could be prevented or worked around? My model objects must remain main- thread-only. Would the "NSObjectController as a file file's owner" pattern [2] help here?

[1] http://www.mail-archive.com/email@hidden/msg17346.html
[2] http://www.borkware.com/quickies/do-search?search=nsobjectcontroller



_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: NSWindowController, bindings and Garbage Collection
      • From: Nikita Zhuk <email@hidden>
  • Prev by Date: [ANN] BWToolkit 1.1 IB Plugin: Codeless Split Views
  • Next by Date: Drawing a badge in an OutlineView column cell: but width changes on expanding
  • Previous by thread: [ANN] BWToolkit 1.1 IB Plugin: Codeless Split Views
  • Next by thread: Re: NSWindowController, bindings and Garbage Collection
  • Index(es):
    • Date
    • Thread