Hi. This is Objective-C, NSDocument based (CoreData document) based application, running long time in production, that suddenly started crashing for me.
I have a main window (naster/detail) presents a relatively large database. Each line when double-clicked, opens a secondary window to show another table of data - related to the selection in the main window. e.g. ID Location Researcher Type Observations 1045 A Sara PhytoPlankton 30 1046 B Merav PhytoPlankton 223 1047 A Diti PhytoPlankton 3219 1056 D Diti PhytoPlankton 2890 Double clicking the line with ID 1045 or 1046, will open a table showing 30/223 “observations” - OK. However, double-clicking lines 1047 or 1056 - will hang a little - then crash with “Bad Access” which I strongly suspect to be something else. My stack trace at the crash is HUGE (about 48300 depth!) It starts reasonably like this: #48271 0x00007fff38f40064 in -[NSController _notifyObserversForKeyPath:change:] () #48272 0x00007fff38f8b47c in -[NSArrayController didChangeValuesForArrangedKeys:objectKeys:indexKeys:] () #48273 0x00007fff38f8cf3f in -[NSArrayController setContent:] () #48274 0x00007fff38f8c93e in -[NSArrayDetailBinder _refreshDetailContentInBackground:] () #48275 0x00007fff38ddc8db in -[NSObject(NSKeyValueBindingCreation) bind:toObject:withKeyPath:options:] () #48276 0x00007fff38d58719 in -[NSIBObjectData nibInstantiateWithOwner:options:topLevelObjects:] () #48277 0x00007fff38d4f991 in loadNib () #48278 0x00007fff38d4eeb5 in +[NSBundle(NSNibLoading) _loadNibFile:nameTable:options:withZone:ownerBundle:] () #48279 0x00007fff38f84aba in +[NSBundle(NSNibLoadingInternal) _loadNibFile:externalNameTable:options:withZone:] () #48280 0x00007fff38f84893 in -[NSWindowController loadWindow] () #48281 0x00007fff38d97cf5 in -[NSWindowController window] () #48282 0x000000010002bdb7 in -[PMXDocumentWindowController showMeasurements:] at /Users/motti/Client Projects/IOLR/PlanktoMetrix II (Cocoa)/planktometrix-ii/PlanktoMetrix-II/PlanktoMetrix-II/PMXDocumentWindowController.m:867 #48283 0x00007fff39520a43 in -[NSApplication(NSResponder) sendAction:to:from:] () #48284 0x00007fff38fc653f in -[NSControl sendAction:to:] () #48285 0x00007fff3903a069 in -[NSTableView _sendAction:to:row:column:] () #48286 0x00007fff390384a8 in -[NSTableView mouseDown:] () #48287 0x00007fff396bfd6d in -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] () #48288 0x00007fff396bc9c4 in -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] () #48289 0x00007fff396bbc70 in -[NSWindow(NSEventRouting) sendEvent:] () #48290 0x00007fff3951d236 in -[NSApplication(NSEvent) sendEvent:] () #48291 0x00007fff38d7d8b5 in -[NSApplication run] () #48292 0x00007fff38d4ca72 in NSApplicationMain () #48293 0x0000000100001a72 in main at /Users/motti/Client Projects/IOLR/PlanktoMetrix II (Cocoa)/planktometrix-ii/PlanktoMetrix-II/PlanktoMetrix-II/main.m:13 #48294 0x00007fff63711015 in start () #48295 0x00007fff63711015 in start () But then continues with an infinite nesting of cocoa-binding related ‘blocks’, that in the end - (topmost calls) crash on NSSQLitConnection connect call - like this: #0 0x00007fff3b342a8d in -[NSSQLiteConnection connect] () #1 0x00007fff3b525c97 in -[NSSQLStoreRequestContext executeRequestUsingConnection:] () #2 0x00007fff3b534f5b in __52-[NSSQLDefaultConnectionManager handleStoreRequest:]_block_invoke () #3 0x00000001004e9d8f in _dispatch_client_callout () #4 0x00000001004fe8bf in _dispatch_queue_barrier_sync_invoke_and_complete () #5 0x00007fff3b534e44 in -[NSSQLDefaultConnectionManager handleStoreRequest:] () #6 0x00007fff3b4755e1 in -[NSSQLCoreDispatchManager routeStoreRequest:] () #7 0x00007fff3b43ce55 in -[NSSQLCore dispatchRequest:withRetries:] () #8 0x00007fff3b3669be in -[NSSQLCore newValuesForObjectWithID:withContext:error:] () #9 0x00007fff3b41a4c4 in __95-[NSPersistentStoreCoordinator(_NSInternalMethods) newValuesForObjectWithID:withContext:error:]_block_invoke () #10 0x00007fff3b40e9e7 in -[NSPersistentStoreCoordinator _routeLightweightBlock:toStore:] () #11 0x00007fff3b3667ae in -[NSPersistentStoreCoordinator(_NSInternalMethods) newValuesForObjectWithID:withContext:error:] () #12 0x00007fff3b3c99fd in __92-[NSManagedObjectContext(_NestedContextSupport) newValuesForObjectWithID:withContext:error:]_block_invoke () #13 0x00007fff3b38ee62 in internalBlockToNSManagedObjectContextPerform () #14 0x00000001004e9d8f in _dispatch_client_callout () #15 0x00000001004fe8bf in _dispatch_queue_barrier_sync_invoke_and_complete () #16 0x00007fff3b38ed6c in _perform () #17 0x00007fff3b38f988 in -[NSManagedObjectContext(_NestedContextSupport) newValuesForObjectWithID:withContext:error:] () #18 0x00007fff3b365eb2 in _PFFaultHandlerLookupRow () #19 0x00007fff3b365700 in _PF_FulfillDeferredFault () #20 0x00007fff3b365517 in _pvfk_header () #21 0x00007fff3b365485 in _sharedIMPL_pvfk_core () #22 0x00007fff3b396cdd in _PF_Handler_Public_GetProperty () #23 0x00007fff3da38636 in -[NSArray(NSKeyValueCoding) _unionOfObjectsForKeyPath:] () #24 0x00007fff3da3880d in -[NSArray(NSKeyValueCoding) _distinctUnionOfObjectsForKeyPath:] () #25 0x00007fff3d90ad3f in -[NSArray(NSKeyValueCoding) valueForKeyPath:] () #26 0x00007fff3d90ab7d in -[NSObject(NSKeyValueCoding) valueForKeyPath:] () #27 0x00007fff38de44ab in -[NSBinder valueForBinding:resolveMarkersToPlaceholders:] () #28 0x00007fff38f8c639 in -[NSArrayDetailBinder _refreshDetailContentInBackground:] () #29 0x00007fff3d9069c9 in NSKeyValueNotifyObserver () Obviously, there is something chaining far-too-many objects here - and I would never guess that normal NSTableColumn bindings are all done nested… still this app runs OK with the same database for customers, and It didn’t crash there before. I wouldn’t even think NSTable should attempt to load ALL the lines despite the fact that only few of them appear in the window initially. Since EVERYTHING in the stack (except for #48282 which is my action to open that window) trace (except #48282 which is my action to open that window) is Cocoa SDK code - I don’t know where to start looking for the culprit. I suspect also, that if I could “untie” something here - my app will also enjoy better responsiveness. The window I’m trying to present has a single, cell-based NSTable, with 10 columns, each bound to the same CoreData entity via ArrayController. There are also 2 custom views in that window’s nib - used within NSAlert dialogs if user elects to use those. Most of the bindings are naive and simple - one column is showing a popup-button whose bindings are little more complicated - but that’s it. Can anyone suggest a way to start bisecting the issue or an idea where to look for? Many thanks. Motti. _______________________________________________ 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
