Your code may not have changed, but Apple's code has - are you still using reference counting? Because I'm willing to bet that NSTableView isn't, and I filed rdar://17733863 over a situation very much like this one - the workaround was to setDelegate:nil earlier than you might think necessary.
On Mar 13, 2015, at 8:11 AM, Peter Hudson <peter.hud...@me.com> wrote: > Thanks for these suggestion Steve and Markus. > > The table datasource and delegate code has been running very sweetly for a > number of years and has not been changed since it was written some time back. > The table datasource in this case is completely central to the program - and > I never change the datasource or delegate for this table. > > That said, the suggestions are interesting - I will try out the debugging > ideas. > My problem is, I can’t reproduce a crash to order ! > This one happened after the user had been working for three hours. > > Peter > > > > >> On 13 Mar 2015, at 14:55, Steve Mills <sjmi...@mac.com> wrote: >> >> On Mar 13, 2015, at 09:46:36, Peter Hudson <peter.hud...@me.com> wrote: >> >>> Crashed Thread: 0 Dispatch queue: com.apple.main-thread >>> >>> Exception Type: EXC_BAD_ACCESS (SIGSEGV) >>> Exception Codes: KERN_INVALID_ADDRESS at 0x00000000ffffffff >>> >>> objc_msgSend() selector name: objectAtIndex: >>> >>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >>> 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27 >>> 1 com.apple.AppKit 0x9184a305 -[NSTableView >>> _dataSourceValueForColumn:row:] + 69 >>> 2 com.apple.AppKit 0x9194e127 -[NSTableView >>> preparedCellAtColumn:row:] + 385 >>> 3 com.apple.AppKit 0x917efc91 -[NSTableView >>> _dirtyVisibleCellsForKeyStateChange] + 878 >> >> What do you have set as the dataSource for the table? Is it still valid when >> the window owning the table becomes key? Is it owned by some object that >> might be in a weak property instead of strong? (Although you would probably >> see that right away when you debugged it.) Have you run static analysis on >> the project? Have you turned on Scribble, Guard Edges, and Guard Malloc in >> your scheme while debugging? Some of those can sometimes help force bugs to >> the surface. >> >> -- >> Steve Mills >> Drummer, Mac geek >> > > > > > On 13/03/15 15:46, Peter Hudson wrote: >> Any comments or suggestions gratefully received ! >> >> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >> 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27 >> 1 com.apple.AppKit 0x9184a305 -[NSTableView >> _dataSourceValueForColumn:row:] + 69 >> 2 com.apple.AppKit 0x9194e127 -[NSTableView >> preparedCellAtColumn:row:] + 385 >> 3 com.apple.AppKit 0x917efc91 -[NSTableView >> _dirtyVisibleCellsForKeyStateChange] + 878 >> 4 com.apple.AppKit 0x917ef6de -[NSTableView >> _windowChangedKeyState] + 323 > > This looks like a table's delegate or datasource has been disposed off while > the table still uses it. Make sure to set table delegates/datasources to nil > when the object being used as delegate/datasource is deallocated. > > Regards > Markus > -- > _______________________________________________ > > 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: > https://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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
