I believe my situation is a bit different and my stack trace is not the same.
What I see in my stack trace is: #0 0x978f8edb in objc_msgSend #1 0x00516f60 in ?? #2 0x98fbb3ea in -[NSTableView preparedCellAtColumn:row:] #3 0x98fd58bc in -[NSTableView _drawContentsAtRow:column:withCellFrame:] #4 0x98fd492a in -[NSTableView drawRow:clipRect:] #5 0x98fd4362 in -[NSTableView drawRowIndexes:clipRect:] #6 0x98fd2d3b in -[NSTableView drawRect:] #7 0x98fc88fd in -[NSView _drawRect:clip:] #8 0x98fc5fc9 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #9 0x98fc695c in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #10 0x98fc695c in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #11 0x98fc695c in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #12 0x98fc695c in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #13 0x98fc555b in -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #14 0x98fc1ea2 in -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] #15 0x98f22a57 in -[NSView displayIfNeeded] #16 0x98eebd40 in -[NSWindow displayIfNeeded] #17 0x98f1d28a in _handleWindowNeedsDisplay #18 0x92548e02 in __CFRunLoopDoObservers #19 0x92504d8d in __CFRunLoopRun #20 0x92504464 in CFRunLoopRunSpecific #21 0x92504291 in CFRunLoopRunInMode #22 0x96351f87 in RunCurrentEventLoopInMode #23 0x964d9ba1 in GetNextEventMatchingMask #24 0x964d9de9 in EventAvail #25 0x00002183 in -[WindowTestAppDelegate applicationDidFinishLaunching:] at WindowTestAppDelegate.m:92 ... ... ... However, if this is not a case where I should be setting the datasource and delegate to nil, but instead is a bug, I would be interested... My sample project will crash every time after the button is pushed. On Jan 19, 2011, at 3:15 PM, Lee Ann Rucker wrote: > Sounds like a radar bug I filed a while back. It was marked as a duplicate of > 6728942 > > From my bug: > > Snow leopard throws a doesNotRecognizeSelector in NSTableView. > > Regression: > Works on Leopard. > > 6 com.apple.ExceptionHandling 0x976b1ebb -[NSExceptionHandler > _handleException:mask:] + 331 > 7 com.apple.ExceptionHandling 0x976b1d52 > NSExceptionHandlerExceptionRaiser + 228 > 8 libobjc.A.dylib 0x916c2776 objc_exception_throw + 56 > 9 com.apple.CoreFoundation 0x9085072b -[NSObject(NSObject) > doesNotRecognizeSelector:] + 187 > 10 com.apple.CoreFoundation 0x907b5ae6 ___forwarding___ + 950 > 11 com.apple.CoreFoundation 0x907b56c2 _CF_forwarding_prep_0 + 50 > 12 com.apple.AppKit 0x95548f9d -[NSTableView > _dataSourceValueForColumn:row:] + 75 > > The dataSource and delegate are connected in nibs and never referenced in our > code, but we can work around this by setting them to nil explicitly when the > window is about to close, so we suspect that it's attempting to use > deallocated objects. > > > On Jan 19, 2011, at 11:55 AM, Eric Gorr wrote: > >> If anyone is interested, this odd crash turns out to be the same issue I was >> struggling with in the 'Window Controllers & Window Deallocation' ( >> http://bit.ly/gzd1LI ) thread. >> >> If in the dealloc method of the table controller, I set the table's >> dataSource and delegate to nil, it will no longer crash. Instruments no >> longer reports any zombies. Upon a normal quit, Instruments does not report >> any leaks either. >> >> Again, the documentation on Weak References can be found at: >> >> Memory Management Programming Guide - Weak References >> >> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#//apple_ref/doc/uid/20000043-1044135-BCICCFAE >> >> Mike Ash has an interesting article on this topic as well: >> >> Zeroing Weak References in Objective-C >> >> http://www.mikeash.com/pyblog/friday-qa-2010-07-16-zeroing-weak-references-in-objective-c.html >> >> >> >> On Jan 12, 2011, at 10:08 AM, Eric Gorr wrote: >> >>> Try grabbing the project again - I have cleaned up a few things which >>> should make this a bit easier. >>> >>> http://ericgorr.net/cocoadev/TableColumnTest.zip >>> >>> It should crash everytime as long as in TableController.m the column are >>> not being removed from the table first. You will have to go in an comment >>> out that line of code yourself. >>> >>> I have also uploaded two screen recordings showing the crash. >>> >>> http://ericgorr.net/cocoadev/TableColumnTestCrash01.m4v >>> http://ericgorr.net/cocoadev/TableColumnTestCrash02.m4v >>> >>> The first movie is just using xcode & the debugger. >>> The second movie is running with zombies. >> >>> >> >>>>>> Am 11.01.2011 um 18:06 schrieb Eric Gorr: >>>>>> >>>>>>> I've got a sample test project at: >>>>>>> >>>>>>> http://ericgorr.net/cocoadev/TableColumnTest.zip >>>>>>> >>>>>>> which reproduces the strange crash. >>>>>>> >>>>>>> I have a NSTableView to which I need to add NSTableColumns manually >>>>>>> using the addTableColumn: method. The problem is that for some reason >>>>>>> when I release the window and everything is being deallocated, someone >>>>>>> has an extra retain on the table column and it sticks around. This >>>>>>> causes a crash because the OS tries to redraw the table which really >>>>>>> isn't there. >>>>>>> >>>>>>> Note: With the code as written, it will only cause a crash >>>>>>> sometimes...if you comment back in the call to the EventAvail function >>>>>>> in WindowTestAppDelegate.m, it will crash every time...this is how I >>>>>>> ended up finding the odd behavior to begin with - I am working with a >>>>>>> cocoa/carbon app and EventAvail is still being called. >>>>>>> >>>>>>> I can avoid the crash if, in my TableController class, I manually >>>>>>> remove the table column from the table first. Is this what I am >>>>>>> expected to do if I manually add the column? I would not have thought >>>>>>> so, but perhaps I am wrong...? >>>>>>> >>>>>>> In TableController.m, I have the function GetNewColumn which creates a >>>>>>> new table column. After I alloc and init the column, I can log the >>>>>>> retain count of the column and see that it is 1. After I call setWidth: >>>>>>> on the table column, I can see that the retain count is 2. >>>>>>> >>>>>>> Can anyone shed some light on what might be going on here and why it is >>>>>>> crashing? >>>>>>> >>>>>>> (if it matters, I am still running on 10.6.5) >> >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> 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: >> http://lists.apple.com/mailman/options/cocoa-dev/lrucker%40vmware.com >> >> This email sent to lruc...@vmware.com > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
