Very occasionally seeing these pop up in crash reports on screens using NSFetchedResultsController, and not sure how to address them. I don't believe I'm using threading anywhere, unless NSFetchedResults is using them internally.
'NSInternalInconsistencyException', reason: 'statement is still active' is the full explanation I get.
Two recent stack traces:
0 CoreFoundation 0x37a368bf __exceptionPreprocess + 163
1 libobjc.A.dylib 0x3151c1e5 objc_exception_throw + 33
2 CoreData 0x340b2ea5 -[NSSQLiteStatement cachedSQLiteStatement] + 1
3 CoreData 0x340b274f -[NSSQLiteConnection prepareSQLStatement:] + 55
4 CoreData 0x34156049 -[NSSQLChannel selectRowsWithCachedStatement:] + 61
5 CoreData 0x34181d63 newFetchedRowsForFetchPlan_MT + 783
6 CoreData 0x340bab07 -[NSSQLCore newRowsForFetchPlan:] + 351
7 CoreData 0x34160011 -[NSSQLCore fetchRowForObjectID:] + 1005
8 CoreData 0x340cca57 -[NSSQLCore newValuesForObjectWithID:withContext:error:] + 195
9 CoreData 0x340cbf83 _PFFaultHandlerLookupRow + 423
10 CoreData 0x340cba97 _PF_FulfillDeferredFault + 187
11 CoreData 0x340cb94f _sharedIMPL_pvfk_core + 39
12 PowerPro 0x0006a779 -[GuestCard getPrimaryProspectiveTenant] (GuestCard.m:77)
13 PowerPro 0x00017bf9 -[OutstandingFollowupsViewController configureCell:atIndexPath:] (OutstandingFollowupsViewController.m:208)
14 PowerPro 0x00017b9b -[OutstandingFollowupsViewController tableView:cellForRowAtIndexPath:] (OutstandingFollowupsViewController.m:203)
Last Exception Backtrace:
0 CoreFoundation 0x37a368bf __exceptionPreprocess + 163
1 libobjc.A.dylib 0x3151c1e5 objc_exception_throw + 33
2 CoreData 0x340b2ea5 -[NSSQLiteStatement cachedSQLiteStatement] + 1
3 CoreData 0x340b274f -[NSSQLiteConnection prepareSQLStatement:] + 55
4 CoreData 0x34156049 -[NSSQLChannel selectRowsWithCachedStatement:] + 61
5 CoreData 0x340c26eb -[NSSQLCore _newRowsForFetchPlan:selectedBy:withArgument:] + 515
6 CoreData 0x340bab3f -[NSSQLCore newRowsForFetchPlan:] + 407
7 CoreData 0x3415ea55 -[NSSQLCore newFetchedPKsForSourceID:andRelationship:] + 2217
8 CoreData 0x3416a935 -[NSSQLCore newValueForRelationship:forObjectWithID:withContext:error:] + 689
9 CoreData 0x34108f8b -[NSFaultHandler retainedFulfillAggregateFaultForObject:andRelationship:withContext:] + 479
10 CoreData 0x340dcb23 -[_NSFaultingMutableSet willRead] + 219
11 CoreData 0x340dc70b -[_NSFaultingMutableSet count] + 23
12 PowerPro 0x00016eb1 -[BrowseGuestCardsViewController configureCell:atIndexPath:] (BrowseGuestCardsViewController.m:246)
13 PowerPro 0x00017173 -[BrowseGuestCardsViewController tableView:cellForRowAtIndexPath:] (BrowseGuestCardsViewController.m:222)
14 UIKit 0x34e4e9cb -[UITableView(UITableViewInternal) _createPreparedCellForGlobalRow:withIndexPath:] + 547
15 UIKit 0x34e4daa9 -[UITableView(_UITableViewPrivate) _updateVisibleCellsNow:] + 1077
16 UIKit 0x34e4d233 -[UITableView layoutSubviews] + 207
17 UIKit 0x34df1d4b -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 183
18 CoreFoundation 0x3799522b -[NSObject performSelector:withObject:] + 43
19 QuartzCore 0x3318c381 -[CALayer layoutSublayers] + 217
20 QuartzCore 0x3318bf99 CA::Layer::layout_if_needed(CA::Transaction*) + 217
21 QuartzCore 0x3318bea5 -[CALayer layoutIfNeeded] + 153
22 UIKit 0x34eb6fe1 -[UIButton titleLabel] + 73
23 PowerPro 0x00017983 -[BrowseGuestCardsViewController viewDidLoad] (BrowseGuestCardsViewController.m:75)
It's more than likely that this is a threading problem in some way or another. There isn't quite enough information in the question to see for sure, but it's worth check through the crash logs and looking at the stack traces for all threads at the time of the exception, and see if any other threads are doing anything which interacts with a managed object. It could be that you have a notification handler, a URL connection completion handler, or some other bit of code using concurrency which you hadn't noticed, using core data objects in the background. It's worth noting that setting or accessing any property on any managed object from a context that's being used on more than one thread could potentially trigger this kind of exception, which can make it pretty tough to diagnose.
The relatively simple solution to solving these problems in most apps is to push the execution of that code to the main thread (using dispatch_async()). Alternatively, if you've got lots of processing to do it might be better to create a child context on the background thread and re-fetch the object from the child context, then save the child context. Of course, to re-fetch the object you need to have its objectID, which is a property which can only be accessed on the thread the object was originally fetched on…
Got this error while simultaneously requesting data with NSFetchedResultController (from main thread context) and NSFetchRequest through my background context.
The way I have handled this is by making each of my MOCs have its own persistent store coordinator. Both of the persistent store coordinators talk to the same persistent store on disk.
Related
I'd like to know if there is anything in the crash stack that will help me get to the root of a "Collection <__NSCFSet: 0x600000986940> was mutated while being enumerated." error. From what I've learned so far, calling save context while enumerating can cause this problem. Although, I thought using .main.async would fix it. It does not. I think I need to figure out how to implement concurrency, but first I'd just like to know where the problem is happening.
0 CoreFoundation 0x0000000106c4f6fb __exceptionPreprocess + 331
1 libobjc.A.dylib 0x0000000105c72ac5 objc_exception_throw + 48
2 CoreFoundation 0x0000000106c4c5cc __NSFastEnumerationMutationHandler + 124
3 CoreData 0x00000001065c688f -[NSManagedObjectContext executeFetchRequest:error:] + 2463
4 ncdrainage 0x0000000104f18e64 $s10ncdrainage15ApplicationDataC18deleteLocalRecords04listF7DeletedySDyS2SG_tF + 1572
5 ncdrainage 0x0000000104f106db $s10ncdrainage15ApplicationDataC15downloadUpdates13finishClosureyySo23UIBackgroundFetchResultVc_tFySo19CKServerChangeTokenCSg_Sbs5Error_pSgtcfU1_ySo14CKRecordZoneIDC_AJ10Foundation0C0VSgSbALtcfU2_ + 1115
6 ncdrainage 0x0000000104f2f09b $s10ncdrainage15ApplicationDataC15downloadUpdates13finishClosureyySo23UIBackgroundFetchResultVc_tFySo19CKServerChangeTokenCSg_Sbs5Error_pSgtcfU1_ySo14CKRecordZoneIDC_AJ10Foundation0C0VSgSbALtcfU2_TA + 59
7 ncdrainage 0x0000000104f109a4 $sSo14CKRecordZoneIDCSo19CKServerChangeTokenCSg10Foundation4DataVSgSbs5Error_pSgIeggggyg_AbESo6NSDataCSgSbSo7NSErrorCSgIeyByyyyy_TR + 372
8 CloudKit 0x00000001054f26a7 -[CKFetchRecordZoneChangesOperation _handleProgressCallback:] + 4864
9 CloudKit 0x00000001054ba54f -[CKOperation _handleProgressCallback:completion:] + 61
10 CloudKit 0x00000001054b6d3c __21-[CKOperation _start]_block_invoke.370 + 216
11 CloudKit 0x00000001055306c5 __68-[CKOperationCallbackManager _performCallbackForOperation:callback:]_block_invoke + 278
12 libdispatch.dylib 0x000000010922d725 _dispatch_block_async_invoke2 + 83
13 libdispatch.dylib 0x000000010921fdb5 _dispatch_client_callout + 8
14 libdispatch.dylib 0x0000000109227225 _dispatch_lane_serial_drain + 778
15 libdispatch.dylib 0x0000000109227ed0 _dispatch_lane_invoke + 477
16 libdispatch.dylib 0x0000000109231ea3 _dispatch_workloop_worker_thread + 733
17 libsystem_pthread.dylib 0x0000000109608611 _pthread_wqthread + 421
18 libsystem_pthread.dylib 0x00000001096083fd start_wqthread + 13
It's not as much as what there is in your crash stack, as what there isn't. Since there is no anything like NSManagedObjectContextPerform, it seems that you don't work with your context in the right thread. You should call code working with context from block submitted to NSManagedObjectContext::perform or NSManagedObjectContext::performAndWait.
So the code should be something like this:
func deleteObjects(context: NSManagedObjectContext) {
context.perform {
let objects = context.fetch(fetchRequest)
for object in objects {
context.delete(object)
}
context.save()
}
}
You can catch such issues in debug by enabling core data concurrency debugging.
I have been tracking a nasty bug recently of which I knew it was occurring due to my multithreaded approach (I add the crashreport at the end).
In my App I load a UITableView and fill it with data I store using Coredata. This data in turn I retrieve from a webservice, thus it might take some time, depending on my connection.
Anyway, I have managed to track it down a little and I know the issue is because an array is empty though I thought it shouldn't be. Then, when
numberOfRowsInSection:(NSInteger)section
is called the program crashes - but only sometimes!!!
I was wondering how to debug this properly and my approach was to call
reloadData
on the tableView after the view finishes loading. But appearantly
- (void)viewDidLoad
but of course this didn't help. Is the correct way here to create another thread and have it check repeatadly whether the data is ready and prepared? Any suggestions/opinions?
2011-01-19 21:50:49.605 myApp[2017:307] *** Terminating app due to uncaught exception
'NSRangeException', reason: '*** -[NSMutableArray objectAtIndex:]: index 0 beyond bounds for empty array'
*** Call stack at first throw:
(
0 CoreFoundation 0x314d0987 __exceptionPreprocess + 114
1 libobjc.A.dylib 0x319a149d objc_exception_throw + 24
2 CoreFoundation 0x31462795 -[__NSArrayM objectAtIndex:] + 184
3 myApp 0x000092f7 -[MyTableViewController tableView:numberOfRowsInSection:] + 106
4 UIKit 0x33902bcf -[UISectionRowData refreshWithSection:tableView:tableViewRowData:] + 1338
5 UIKit 0x33903529 -[UITableViewRowData(UITableViewRowDataPrivate) _ensureSectionOffsetIsValidForSection:] + 120
6 UIKit 0x33902645 -[UITableViewRowData numberOfRows] + 96
7 UIKit 0x3390207b -[UITableView noteNumberOfRowsChanged] + 82
8 UIKit 0x33901bff -[UITableView reloadData] + 582
9 UIKit 0x33904a0b -[UITableView _reloadDataIfNeeded] + 50
10 UIKit 0x33904e63 -[UITableView layoutSubviews] + 18
11 UIKit 0x338b10cf -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 26
12 CoreFoundation 0x3146ebbf -[NSObject(NSObject) performSelector:withObject:] + 22
13 QuartzCore 0x30a6c685 -[CALayer layoutSublayers] + 120
14 QuartzCore 0x30a6c43d CALayerLayoutIfNeeded + 184
15 QuartzCore 0x30a6656d _ZN2CA7Context18commit_transactionEPNS_11TransactionE + 212
16 QuartzCore 0x30a66383 _ZN2CA11Transaction6commitEv + 190
17 QuartzCore 0x30a70e4f _ZN2CA11Transaction5flushEv + 46
18 QuartzCore 0x30a6db75 +[CATransaction flush] + 24
19 UIKit 0x338e803f -[UIApplication _reportAppLaunchFinished] + 30
20 UIKit 0x338d6317 -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 462
21 UIKit 0x338a248b -[UIApplication handleEvent:withNewEvent:] + 1114
22 UIKit 0x338a1ec9 -[UIApplication sendEvent:] + 44
23 UIKit 0x338a1907 _UIApplicationHandleEvent + 5090
24 GraphicsServices 0x35d66f03 PurpleEventCallback + 666
25 CoreFoundation 0x314656ff __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 26
26 CoreFoundation 0x314656c3 __CFRunLoopDoSource1 + 166
27 CoreFoundation 0x31457f7d __CFRunLoopRun + 520
28 CoreFoundation 0x31457c87 CFRunLoopRunSpecific + 230
29 CoreFoundation 0x31457b8f CFRunLoopRunInMode + 58
30 UIKit 0x338d5309 -[UIApplication _run] + 380
31 UIKit 0x338d2e93 UIApplicationMain + 670
32 myApp 0x000029bf main + 70
33 myApp 0x00002974 start + 40
)
terminate called after throwing an instance of 'NSException'
numberOfRows looks like:
- (NSInteger)tableView:(UITableView *)aTableView numberOfRowsInSection:(NSInteger)section {
// Return the number of rows in the section.
NSLog(#"number of rows in section");
if (section == mySection) {
return [[articleArrays objectAtIndex:section] count];
} else {
return 0;
}
}
From what you describe here your process that performs the download, or more precisely an event callback should be the only place calling reload data. calling it after adding new data to the table dataSet.
returning a 0 in numberOfRowsInSection does not cause a crash but if you are trying to get a nested array when the count is 0, this will crash. Post your numberOfRowsInSection method for us to gawk at.
EDIT:
Sounds/Looks like background thread is mutating the array while its trying to do an object count.
user210504 is right in saying that synchronising the array is likely stop this.
Typically you would sync writes and therefore preventing numberOfRowsInSection from counting if your background thread is mutating it. eg:
-(void)downloadFinished{
NSMutableArray * array = [[NSArray alloc] init];//t
id * obj;//obj is your row data object.
#synchronized(ar)
{
[array addObject:obj];//ar is your dataSet
}
[array release];
}
One thing that you can do is to encapsulate accesses to the Mutable Array in #synchronized block. This way you will be sure that you are not accessing the datastructure half way through. And then I also agree with what Luke just mentioned.
I am trying to figure out what is causing this crash. I have built and given the app to our testers but we cannot seem to reproduce this reliably. It just happens sometimes...
Thread 0 Crashed:
0 libobjc.A.dylib 0x000027da objc_msgSend + 18
1 Foundation 0x00032896 -[NSURLConnection(NSURLConnectionReallyInternal) sendDidFinishLoading] + 62
2 Foundation 0x00032818 _NSURLConnectionDidFinishLoading + 72
3 CFNetwork 0x00010dd8 URLConnectionClient::_clientDidFinishLoading(URLConnectionClient::ClientConnectionEventQueue*) + 160
4 CFNetwork 0x00004ad4 URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload(XConnectionEventInfo<XClientEvent, XClientEventParams>*, long) + 96
5 CFNetwork 0x000049c4 URLConnectionClient::processEvents() + 64
6 CFNetwork 0x00004976 URLConnection::multiplexerClientPerform(RunLoopMultiplexer*) + 30
7 CFNetwork 0x000048f4 MultiplexerSource::perform() + 120
8 CFNetwork 0x00004872 MultiplexerSource::_perform(void*) + 2
9 CoreFoundation 0x00055f1e __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 6
10 CoreFoundation 0x00027ba0 __CFRunLoopDoSources0 + 376
11 CoreFoundation 0x00027444 __CFRunLoopRun + 224
12 CoreFoundation 0x00027270 CFRunLoopRunSpecific + 224
13 CoreFoundation 0x00027178 CFRunLoopRunInMode + 52
14 GraphicsServices 0x000045ec GSEventRunModal + 108
15 GraphicsServices 0x00004698 GSEventRun + 56
16 UIKit 0x0000411c -[UIApplication _run] + 396
17 UIKit 0x00002128 UIApplicationMain + 664
18 myapp 0x000020d8 main (main.m:14)
19 myapp 0x0000208c start + 32
Any advice would be greatly appreciated. The app is built in XCode 3.2.4 using SDK 4.1.
Cheers...
I would try turning on NSZombieEnabled and see if that sheds any light on the issue. Is the delegate for the connection still around and valid?
Ben has some sound advice. Turn NSZombieEnabled to on.
I can tell you with almost 100% certainty that it is crashing because you have a nil object when the delegate is attempting to send it a message.
The fact that it is only crashing sometimes, tells me that you are probably using autorelease. Autorelease never decrements the retain count at exactly the same time, so sometimes your object will still be alive when it gets a delegate message and the app works. However, sometimes that object will have been released and the app crashes.
my app is based around two classes: Jam and JamItem, each with a TableViewController to display / add items.
The model contains two entities for the two classes, and there is an optional one-to-one relationship between them. JamItem has a name field and a price field. Jam has a quantity field. There are corresponding NSManagedObject classes for the two entities.
Both lists are based on table list view controllers and were modelled on the Recipes example on the Apple site. The JamListTableViewController displays all JamItem instances that have been added to the list. When I click add, a new instance of JamItemListTableViewController is created and pushed onto the nav stack. This lists JamItem instances that have been created. When a JamItem is selected, the - (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath method creates an instance of JamItem and passes it back via a delegate to JamListTableViewController. This then creates a new instance of Jam and adds the JamItem to it and then saves.
I can run the app perfectly when it is fresh on the simulator and run the first time with a clean database!
The JamItemListTableViewController always works and I can happily add and remove 'jam items' from the list. However, if I stop the app and re-run, then try to add a new JamItem to the jam list (JamListTableViewController), it crashes when JamListTableViewController calls the [jam.managedObjectContext save:&error] and I get the error below, which I think is where it is trying to sort by name.
The NSFetchedResultsController in JamItemListTableViewController is configured to order by name. The NSFetchedResultsController in JamItemListTableViewController is ordered by JamItem.name
I hope this makes sense as I have been pulling my hair out for weeks now trying to find the solution. I think I might have (or have not) released an object, which is causing the JamItem list to flag that it has been updated and start trying to re-sort its list.
This is the dump of the error:
2010-09-29 07:20:00.443 Jams[12451:207] Serious application error. Exception was caught during Core Data change processing. This is usually a bug within an observer of NSManagedObjectContextObjectsDidChangeNotification. [<UINavigationItem 0x5b4dc30> valueForUndefinedKey:]: this class is not key value coding-compliant for the key name. with userInfo {
NSTargetObjectUserInfoKey = "<UINavigationItem: 0x5b4dc30>";
NSUnknownUserInfoKey = name;
}
2010-09-29 07:20:00.446 Jams[12451:207] *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<UINavigationItem 0x5b4dc30> valueForUndefinedKey:]: this class is not key value coding-compliant for the key name.'
*** Call stack at first throw:
(
0 CoreFoundation 0x02577919 __exceptionPreprocess + 185
1 libobjc.A.dylib 0x026c55de objc_exception_throw + 47
2 CoreFoundation 0x02577851 -[NSException raise] + 17
3 Foundation 0x000d96b1 -[NSObject(NSKeyValueCoding) valueForUndefinedKey:] + 279
4 Foundation 0x00040868 _NSGetUsingKeyValueGetter + 147
5 Foundation 0x0003fd2e -[NSObject(NSKeyValueCoding) valueForKey:] + 278
6 Foundation 0x00043535 -[NSObject(NSKeyValueCoding) valueForKeyPath:] + 381
7 Foundation 0x000f7c4f -[NSSortDescriptor compareObject:toObject:] + 128
8 CoreData 0x0237cb5e +[NSFetchedResultsController(PrivateMethods) _insertIndexForObject:inArray:lowIdx:highIdx:sortDescriptors:] + 286
9 CoreData 0x0237d1b2 -[NSFetchedResultsController(PrivateMethods) _postprocessInsertedObjects:] + 402
10 CoreData 0x023831bc -[NSFetchedResultsController(PrivateMethods) _managedObjectContextDidChange:] + 1804
11 Foundation 0x00035c1d _nsnote_callback + 145
12 CoreFoundation 0x0254fcf9 __CFXNotificationPost_old + 745
13 CoreFoundation 0x024cf11a _CFXNotificationPostNotification + 186
14 Foundation 0x0002b7c2 -[NSNotificationCenter postNotificationName:object:userInfo:] + 134
15 CoreData 0x022bf519 -[NSManagedObjectContext(_NSInternalNotificationHandling) _postObjectsDidChangeNotificationWithUserInfo:] + 89
16 CoreData 0x0232eb33 -[NSManagedObjectContext(_NSInternalChangeProcessing) _createAndPostChangeNotification:withDeletions:withUpdates:withRefreshes:] + 259
17 CoreData 0x022a1f78 -[NSManagedObjectContext(_NSInternalChangeProcessing) _processRecentChanges:] + 1352
18 CoreData 0x022dba15 -[NSManagedObjectContext save:] + 149
19 JamsApp 0x000064b3 -[JamsListTableViewController insertJamItem:] + 168
20 JamsApp 0x00006405 -[JamsListTableViewController selectedJamItem:] + 43
21 JamsApp 0x00003f41 -[JamItemListTableViewController tableView:didSelectRowAtIndexPath:] + 143
22 UIKit 0x0033d718 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 1140
23 UIKit 0x00333ffe -[UITableView _userSelectRowAtIndexPath:] + 219
24 Foundation 0x0004acea __NSFireDelayedPerform + 441
25 CoreFoundation 0x02558d43 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 19
26 CoreFoundation 0x0255a384 __CFRunLoopDoTimer + 1364
27 CoreFoundation 0x024b6d09 __CFRunLoopRun + 1817
28 CoreFoundation 0x024b6280 CFRunLoopRunSpecific + 208
29 CoreFoundation 0x024b61a1 CFRunLoopRunInMode + 97
30 GraphicsServices 0x02ddc2c8 GSEventRunModal + 217
31 GraphicsServices 0x02ddc38d GSEventRun + 115
32 UIKit 0x002d9b58 UIApplicationMain + 1160
33 JamsApp 0x00001c0c main + 102
34 JamsApp 0x00001b9d start + 53
)
terminate called after throwing an instance of 'NSException'
I'd say check your nib to see if you have a connection to name, where name doesn't exist, but in suspect it would crash the first time too. Recheck everywhere you define name.
Ok, so I fixed it myself.
I am not completely sure what was going on, but it's seems to me that a field that was there originally and then removed, seemed to be in the core data somewhere?
Anyway, the fix for me was to remove all the core data files and managed object files and delete the instance of the app in the sim, and start again.
It took minutes to do and solved the problem - now jam can flow happily again!
I would have rather solved the problem, however time is in short supply and I already spent too many hours looking at it!
Recently, I've been getting intermittent error reports from my app claiming "unrecognized selector" in areas that could not possibly cause them, and yet they do.
For example, this one:
Error: NSInvalidArgumentException: *** -[NSCFString didReceiveMemoryWarning]: unrecognized selector sent to instance 0x541fe0
0 CoreFoundation 0x32de1e23 __handleUncaughtException + 230
1 libobjc.A.dylib 0x3266d894 _objc_terminate + 156
2 libstdc++.6.dylib 0x338c3a8c _ZN10__cxxabiv111__terminateEPFvvE + 84
3 libstdc++.6.dylib 0x338c3b04 _ZSt9terminatev + 24
4 libstdc++.6.dylib 0x338c3c2c __cxa_throw + 108
5 libobjc.A.dylib 0x3266be5c objc_exception_throw + 112
6 CoreFoundation 0x32de2bfd -[NSObject doesNotRecognizeSelector:] + 112
7 CoreFoundation 0x32d67b19 ___forwarding___ + 480
8 CoreFoundation 0x32d5e840 _CF_forwarding_prep_0 + 48
9 Foundation 0x33f765d9 _nsnote_callback + 184
10 CoreFoundation 0x32d9e511 _CFXNotificationPostNotification + 304
11 Foundation 0x33f741b3 -[NSNotificationCenter postNotificationName:object:userInfo:] + 70
12 Foundation 0x33f76519 -[NSNotificationCenter postNotificationName:object:] + 20
13 UIKit 0x30d18db8 -[UIApplication _performMemoryWarning] + 68
14 UIKit 0x30d18d50 -[UIApplication _receivedMemoryNotification] + 136
15 UIKit 0x30d18c80 _memoryStatusChanged + 64
16 CoreFoundation 0x32d66eb7 __CFNotificationCenterDarwinCallBack + 26
17 CoreFoundation 0x32d5cb51 __CFMachPortPerform + 78
18 CoreFoundation 0x32da452b CFRunLoopRunSpecific + 2302
19 CoreFoundation 0x32da3c1f CFRunLoopRunInMode + 50
20 GraphicsServices 0x31bb9374 GSEventRunModal + 196
21 UIKit 0x30bf3c30 -[UIApplication _run] + 560
22 UIKit 0x30bf2230 UIApplicationMain + 968
23 Mind 0x00002c68 main + 72
24 Mind 0x00002be4 start + 52
This is the OS sending a memory warning to my app, and somehow the application class has changed into a string.
It seems to happen a lot more when the code is invoked via an NSOperation:
Error: NSInvalidArgumentException: -[NSCFString setObject:forKey:]: unrecognized selector sent to instance 0x3e793088
9 Mind 0x0015de70 -[CCTextureCache textureFromFile:] + 528
10 Mind 0x0015d9f4 -[CCTextureCache loadImageUncached:pixelFormat:] + 116
11 Mind 0x0015d058 -[CCTextureCache addImage:pixelFormat:] + 152
12 Mind 0x00080524 -[ImageLoader imageWithFile:pixelFormat:] + 84
13 Mind 0x000854c4 -[ImageLoadOperation performLoad] + 68
14 Mind 0x00085800 -[ResourceLoadOperation main] + 112
15 Foundation 0x30c4c8b5 -[__NSOperationInternal start] + 664
16 Foundation 0x30c4c613 -[NSOperation start] + 22
17 Foundation 0x30cbdb63 ____startOperations_block_invoke_2 + 46
18 libSystem.B.dylib 0x31227858 _dispatch_call_block_and_release + 20
19 libSystem.B.dylib 0x3122863c _dispatch_worker_thread2 + 128
20 libSystem.B.dylib 0x311b1544 _pthread_wqthread + 400
21 libSystem.B.dylib 0x311a8b74 __stack_chk_fail + 4294967295
The code in question is:
[textures setObject:texture forKey:filename];
textures is type NSMutableDictionary* and never gets reassigned or deallocated (naturally, since this is a cache object). This is the only place where setObject is invoked in this method, yet according to the stack trace, textures was a string.
I also get this weirdness:
Error: NSInvalidArgumentException: -[NSConcreteNotification getPixelFormatForIdentifier:]: unrecognized selector sent to instance 0x5c021b0
9 Mind 0x0015dd0c -[CCTextureCache textureFromFile:] + 172
10 Mind 0x0015d9f4 -[CCTextureCache loadImageUncached:pixelFormat:] + 116
11 Mind 0x0015d058 -[CCTextureCache addImage:pixelFormat:] + 152
12 Mind 0x00080524 -[ImageLoader imageWithFile:pixelFormat:] + 84
13 Mind 0x000854c4 -[ImageLoadOperation performLoad] + 68
14 Mind 0x00085800 -[ResourceLoadOperation main] + 112
15 Foundation 0x347b78b5 -[__NSOperationInternal start] + 664
16 Foundation 0x347b7613 -[NSOperation start] + 22
17 Foundation 0x34828b63 ____startOperations_block_invoke_2 + 46
18 libSystem.B.dylib 0x32a2f858 _dispatch_call_block_and_release + 20
19 libSystem.B.dylib 0x32a3063c _dispatch_worker_thread2 + 128
20 libSystem.B.dylib 0x329b9544 _pthread_wqthread + 400
21 libSystem.B.dylib 0x329b0b74 __stack_chk_fail + 4294967295
This trace is from the following code in CCTextureCache:
CCTexture2DPixelFormat pixelFormat = [self getPixelFormatForIdentifier:identifier];
How CCTextureCache changed into NSConcreteNotification after having already called a number of methods on itself is baffling to say the least.
Has anyone else noticed this sort of thing? Am I somehow getting memory corruption?
Did you check some race conditions about multi-threads ? It seems like some resource freed by another thread, and current thread send a messaged to a deallocated object.
Error: NSInvalidArgumentException: -[NSCFString setObject:forKey:]: unrecognized selector sent to instance 0x3e793088
9 Mind 0x0015de70 -[CCTextureCache textureFromFile:] + 528
10 Mind 0x0015d9f4 -[CCTextureCache loadImageUncached:pixelFormat:] + 116
11 Mind 0x0015d058 -[CCTextureCache addImage:pixelFormat:] + 152
12 Mind 0x00080524 -[ImageLoader imageWithFile:pixelFormat:] + 84
13 Mind 0x000854c4 -[ImageLoadOperation performLoad] + 68
14 Mind 0x00085800 -[ResourceLoadOperation main] + 112
15 Foundation 0x30c4c8b5 -[__NSOperationInternal start] + 664
16 Foundation 0x30c4c613 -[NSOperation start] + 22
17 Foundation 0x30cbdb63 ____startOperations_block_invoke_2 + 46
18 libSystem.B.dylib 0x31227858 _dispatch_call_block_and_release + 20
19 libSystem.B.dylib 0x3122863c _dispatch_worker_thread2 + 128
20 libSystem.B.dylib 0x311b1544 _pthread_wqthread + 400
21 libSystem.B.dylib 0x311a8b74 __stack_chk_fail + 4294967295
This is often caused by memory management errors. Did you try zombies?
...with zombies enabled, messages to deallocated objects will no longer behave
strangely or crash in difficult-to-understand ways, but will instead log a message
and die in a predictable and debugger-breakpointable way. This is the tool to use
when trying to track down over-releases and premature releases.
I just ran into the same problem, but it turns out I had made a stupid mistake:
I had declared a member like this in the header file:
NSMutableDictionary* myDict;
But then initialized it like this in the .m file:
myDict = [[NSDictionary alloc] init];
which is valid and all, because the NSMutableDictionary is derived from the NSDictionary class. Therefore all calls that are inherited from NSDictionary actually worked, but the calls specific to NSMutableDictionary [setObject: forKey:] failed because I tried to invoke them on the parent class.
The mistake was really dumb, but I was also thrown off by the fact that the debugger reported the type of myDict as something totally different (neither NSDictionary, nor NSMutableDictionary). I hope this helps some other tired coder :-)