I'm having an issue where some users are getting a crash on launch in my native iOS app using MagicalRecord (shorthand) v2.2.
This is not a classic database migration issue as firstly it doesn't occur for all users, and secondly the database schema has not been changed (I have git logs proving this and just in case I tried to reproduce after making some db changes but was not successful).
Deleting and recreating the database does seem to work however as the fallback code in the app clears and recreates the database if it has detected that it has crashed due to this issue previously. The crash logs indicate that this works as there is a 1 to 1 ratio of unique devices and number of crashes.
All that happens on launch related to the db is the following:
[MagicalRecord setErrorHandlerTarget:self action:#selector(handleCoreDataError:)];
[MagicalRecord setupCoreDataStackWithAutoMigratingSqliteStoreNamed:#"xxx.sqlite"];
The stack trace on the main thread:
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x37d3f626 objc_msgSend + 5
1 Foundation 0x2dec102d -[NSError dealloc] + 60
2 libobjc.A.dylib 0x37d44b6b objc_object::sidetable_release(bool) + 174
3 libobjc.A.dylib 0x37d450d3 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 358
4 CoreFoundation 0x2d4d24c1 _CFAutoreleasePoolPop + 16
5 Foundation 0x2decb8e3 -[NSAutoreleasePool drain] + 122
6 CoreData 0x2d312fbf -[NSManagedObjectContext save:] + 942
7 xxx 0x00249223 __70-[NSManagedObjectContext(MagicalSaves) MR_saveWithOptions:completion:]_block_invoke3 (NSManagedObjectContext+MagicalSaves.m:64)
8 CoreData 0x2d3769cd developerSubmittedBlockToNSManagedObjectContextPerform + 88
9 libdispatch.dylib 0x3821ed3f _dispatch_client_callout + 22
10 libdispatch.dylib 0x382216c3 _dispatch_main_queue_callback_4CF + 278
11 CoreFoundation 0x2d569681 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
12 CoreFoundation 0x2d567f4d __CFRunLoopRun + 1308
13 CoreFoundation 0x2d4d2769 CFRunLoopRunSpecific + 524
14 CoreFoundation 0x2d4d254b CFRunLoopRunInMode + 106
15 GraphicsServices 0x3243f6d3 GSEventRunModal + 138
16 UIKit 0x2fe31891 UIApplicationMain + 1136
17 xxx 0x0002e3cc main (main.m:18)
Well, this error seems like you're overreleasing the error object. Are you explicitly calling [error release] or [error autorelease] somewhere?
Related
I got this crash from crashlytics. Do you know what is that mean? The crashlytics says; 100% crash from ios 10. I searched this bug, but I couldn't anything about it.
Edit: Crash Title
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000000
0 libobjc.A.dylib 0x186af6f30 objc_msgSend + 16
1 StoreKit 0x194ad1d0c <redacted> + 52
2 libdispatch.dylib 0x186f35200 _dispatch_call_block_and_release + 24
3 libdispatch.dylib 0x186f351c0 _dispatch_client_callout + 16
4 libdispatch.dylib 0x186f39d6c _dispatch_main_queue_callback_4CF + 1000
5 CoreFoundation 0x188059f2c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
6 CoreFoundation 0x188057b18 __CFRunLoopRun + 1660
7 CoreFoundation 0x187f86048 CFRunLoopRunSpecific + 444
8 GraphicsServices 0x189a09198 GSEventRunModal + 180
9 UIKit 0x18df60628 <redacted> + 684
10 UIKit 0x18df5b360 UIApplicationMain + 208
11 AppName 0x100126770 main (main.m:15)
12 libdispatch.dylib 0x186f685b8 (Missing)
EXC_BAD_ACCESS errors often occur when trying to send a message to an object that has been deallocated, or to nil.
In this case, the associated address 0x0000000000000000 and the top item objc_msgSend makes it pretty clear: a message was sent to a nil/null object.
If your code works on previous version of iOS, it may be because the object isn't being released at the same time, or because there is some new behavior of the APIs you are using that you aren't handling (for example: maybe an earlier function/API call now returns nil in iOS 10, but you just pass that through to somewhere else without checking it).
I have one user, and only one user, that regularly gets the following crash:
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x0000000192e7a984 objc_object::release() + 8
1 libobjc.A.dylib 0x0000000192e79474 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 524
2 CoreFoundation 0x0000000186855b38 _CFAutoreleasePoolPop + 28
3 CoreFoundation 0x0000000186915124 __CFRunLoopRun + 1460
4 CoreFoundation 0x0000000186855dd0 CFRunLoopRunSpecific + 452
5 GraphicsServices 0x000000018c53dc0c GSEventRunModal + 168
6 UIKit 0x0000000189986fc4 UIApplicationMain + 1156
7 MyApp 0x00000001001a92d0 main (main.m:17)
8 libdyld.dylib 0x0000000193453aa0 start + 4
This is the entire crash, and I have no clue what causes it.
The user has a pretty standard phone, but it only started happening when they got a replacement iPhone 5 earlier this year. Given that timeline and the fact they are the only one with the crash, might the phone itself be at fault?
Is there anywhere I could look for more information to default this information?
I'm having trouble reproducing the crash detailed below (got it from crash analytics/tracking). There always also appears to be another suspect looking thread running alongside the crashed thread at the same time on every instance of the crash reported:
Crashed Thread
0 CoreFoundation 0x2f9074be CFGetTypeID + 6
1 CoreFoundation 0x2f91e47b _flattenPlist + 47
2 CoreFoundation 0x2f91e57f _flattenPlist + 307
3 CoreFoundation 0x2f98257b __CFBinaryPlistWrite + 131
4 CoreFoundation 0x2f91e321 CFPropertyListWrite + 245
5 CoreFoundation 0x2f92e731 CFPropertyListWriteToStream + 145
6 CoreFoundation 0x2f92c39d _CFXPreferencesWritePlist + 269
7 CoreFoundation 0x2f92c28b -[CFXPreferencesPropertyListSourceSynchronizer writePlistToDisk] + 131
8 CoreFoundation 0x2f929aef -[CFXPreferencesPropertyListSourceSynchronizer synchronizeAlreadyFlocked] + 487
9 CoreFoundation 0x2f929905 -[CFXPreferencesPropertyListSourceSynchronizer synchronize] + 21
10 CoreFoundation 0x2f929405 __79-[CFXPreferencesPropertyListSource synchronizeInBackgroundWithCompletionBlock:]_block_invoke + 101
11 libdispatch.dylib 0x3a656d53 _dispatch_call_block_and_release + 11
12 libdispatch.dylib 0x3a65bcbd _dispatch_queue_drain + 489
13 libdispatch.dylib 0x3a658c6f _dispatch_queue_invoke + 43
14 libdispatch.dylib 0x3a65c5f1 _dispatch_root_queue_drain + 77
15 libdispatch.dylib 0x3a65c8dd _dispatch_worker_thread2 + 57
16 libsystem_pthread.dylib 0x3a787c17 _pthread_wqthread + 299
17 libsystem_pthread.dylib 0x3a787adc start_wqthread + 8
Other suspect thread (that always runs at the same time and looks like it's related):
0 libsystem_kernel.dylib 0x3a70faa0 semaphore_wait_trap + 8
1 libdispatch.dylib 0x3a65b513 _dispatch_barrier_sync_f_slow + 139
2 CoreFoundation 0x2f94424d CFPreferencesAppSynchronize + 265
3 Foundation 0x3032e91d -[NSUserDefaults(NSUserDefaults) synchronize] + 25
4 MailOnline 0x00280897 ADBLifecycleStart + 2495
5 CoreFoundation 0x2f998f41 _CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 13
6 CoreFoundation 0x2f90cda9 _CFXNotificationPost + 1721
7 Foundation 0x302f7cc5 -[NSNotificationCenter postNotificationName:object:userInfo:] + 73
8 UIKit 0x3246747f -[UIApplication _sendWillEnterForegroundCallbacks] + 155
9 UIKit 0x3240c88b -[UIApplication _handleApplicationResumeEvent:] + 927
10 UIKit 0x3220b613 -[UIApplication handleEvent:withNewEvent:] + 1883
11 UIKit 0x3220adf9 -[UIApplication sendEvent:] + 73
12 UIKit 0x3226f405 _UIApplicationHandleEvent + 617
13 GraphicsServices 0x34878b55 _PurpleEventCallback + 609
14 GraphicsServices 0x3487873f PurpleEventCallback + 35
15 CoreFoundation 0x2f9a1847 _CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 35
16 CoreFoundation 0x2f9a17e3 __CFRunLoopDoSource1 + 347
17 CoreFoundation 0x2f99ffaf __CFRunLoopRun + 1407
18 CoreFoundation 0x2f90a769 CFRunLoopRunSpecific + 525
19 CoreFoundation 0x2f90a54b CFRunLoopRunInMode + 107
20 GraphicsServices 0x348776d3 GSEventRunModal + 139
21 UIKit 0x32269891 UIApplicationMain + 1137
22 MailOnline 0x000cd18b main (main.m:16)
23 libdyld.dylib 0x3a66bab7 start + 3
When debugging the running program it appears that the Adobe Mobile SDK we use for tracking listens to the return to foreground event fired by the OS and then calls synchronize on the NSUserDefaults (see Other suspect thread). The synchronize then breaks off into another thread (the crashed thread) but then it crashes for some reason when trying to write to a plist file.
I cannot reproduce the crash. We are using v4.0 of the Adobe Mobile Library iOS SDK so if anyone else has had similar crashes with these SDKs then please help!? Or if anyone has any suggestions for steps to make this crash more likely to happen (e.g. I've tried writing to plist constantly when the SDK runs to see if it was a threading issue but with no luck) then please advise...
NOTE: This issue is still happening on newer devices running iOS 7 but still does not ever occur on devices running iOS 8.0 or 8.1.
This issue is due to a race condition inside of NSUserDefaults itself. The following code snippet will reproduce the issue in an isolated scenario(You'll need to let this code run for 15-30 seconds to expose the issue):
dispatch_async(dispatch_get_main_queue(), ^{
while(true) {
for(int i = 0; i < 20000; i++) {
[[NSUserDefaults standardUserDefaults] setObject: #"value" forKey: [NSString stringWithFormat: #"blah%d",i]];
}
for(int i = 0; i < 20000; i++) {
[[NSUserDefaults standardUserDefaults] removeObjectForKey: [NSString stringWithFormat: #"blah%d",i]];
}
}
});
Other people have reported this issue, clearest example of this being this post on the apple developer forums(registration required).
My recommendation would be to check your code for any significant read/write cycles into NSUserDefaults. If you need to do a massive amount of changes or updates to data, you probably want to roll your own persistence layer instead of NSUserDefaults until this issue is resolved by Apple.
The ADBLifecycleStart method is a red-herring in this scenario. This code runs on it's own queue, and will probably be living (or at least caught by a full thread dump) most of the time. The ADBLifeCycleStart method makes a worst case total of 13 writes to NSUserDefaults, followed by a synchronize.
Note: At WWDC this year, Apple Engineers confirmed that NSUserDefaults got a total rewrite. After some testing, this issue appears to have been resolved and is no longer reproducible running iOS 8.
Henry,
On launch, the sdk updates some items stored in NSUserDefaults. After those items are updated, NSUserDefaults attempts to synchronize which updates the NSUserDefaults plist. It looks like the application is crashing at the point when the device is attempting to update that plist. After some investigation it seems that this can happen for a couple different reasons. 1) If zombie mode is turned on (causing memory to never be freed) and your app reaches 4GB per-process, 2) The nsuserdefaults plist has become corrupt.
-Hunter
I have an application in which I have links for some videos and when requested by user I download the video files. The downloaded video files are listed in a UITableView. The app crashes occasionally with crash log similar to following.
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x6000000c
Triggered by Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x3a03fb26 objc_msgSend + 6
1 MediaPlayer 0x30ba3ff0 -[MPAVController _setState:] + 288
2 MediaPlayer 0x30b97f1a -[MPAVController pauseWithFadeout:] + 198
3 MediaPlayer 0x30b9cd22 -[MPAVController _itemPlaybackDidEndNotification:] + 786
4 CoreFoundation 0x2f90011e __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 10
5 CoreFoundation 0x2f874312 _CFXNotificationPost + 1714
6 AVFoundation 0x2e780b6e __avplayeritem_fpItemNotificationCallback_block_invoke + 4094
7 libdispatch.dylib 0x3a527d78 _dispatch_call_block_and_release + 8
8 libdispatch.dylib 0x3a527d64 _dispatch_client_callout + 20
9 libdispatch.dylib 0x3a52e7bc _dispatch_main_queue_callback_4CF$VARIANT$mp + 264
10 CoreFoundation 0x2f90881c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 4
11 CoreFoundation 0x2f9070f0 __CFRunLoopRun + 1296
12 CoreFoundation 0x2f871ce2 CFRunLoopRunSpecific + 518
13 CoreFoundation 0x2f871ac6 CFRunLoopRunInMode + 102
14 GraphicsServices 0x3455f27e GSEventRunModal + 134
15 UIKit 0x32113a3c UIApplicationMain + 1132
16 MyApp 0x000e5884 main (main.m:30)
17 libdyld.dylib 0x3a54cab4 start + 0
The problem is that none of my own methods are shown to fail in the log. All calls seem to be library method calls. Also I wonder why _itemPlaybackDidEndNotification: was called as I encountered this when I was not even playing a video.
Can someone help?
I found the issue in my case. I was using thumbnailImageAtTime:timeOption: which seems to play/pause the video in the background(This is just my conjecture though) to get a thumbnail for it. That caused the itemPlaybackDidEndNotification to fire despite me not playing any video explicitly and cause further issues.
There are now a couple of alternatives if someone else is using same method for getting thumbnails. The methods are mentioned here. thumbnailImageAtTime: now deprecated - What's the alternative?
I am developing an application which uses CoreData. The view contains a UITableView (containing around 50 elements) which uses a NSFetchedResultsController. There is also a "Pull to refresh" which permits to refresh the stored data after a WS call (in another thread with a new managed object context).
Everything is working fine on iOS5: the database and the tableview are refreshed when I perform a "Pull to refresh". However there is a problem with iOS4. The first "performFetch" works when the application is launched (the tableview contains all database records) but I've got the following error when I perform a "Pull to refresh":
2012-02-29 11:56:09.119 Nanopost[1996:207] *** Terminating app due to uncaught exception 'NSObjectInaccessibleException', reason: 'CoreData could not fulfill a fault for '0x5c3c760 <x-coredata://E176B0A1-275B-4332-9231-49FD88238C2B/Ads/p231>''
*** Call stack at first throw:
(
0 CoreFoundation 0x02bfe919 __exceptionPreprocess + 185
1 libobjc.A.dylib 0x02e595de objc_exception_throw + 47
2 CoreData 0x028b833f _PFFaultHandlerLookupRow + 1407
3 CoreData 0x028b5ee3 _PF_FulfillDeferredFault + 499
4 CoreData 0x028b9f3f _sharedIMPL_pvfk_core + 95
5 CoreData 0x0292a010 _PF_Handler_Public_GetProperty + 160
6 Foundation 0x02442c4f -[NSSortDescriptor compareObject:toObject:] + 128
7 CoreData 0x0297db5e +[NSFetchedResultsController(PrivateMethods) _insertIndexForObject:inArray:lowIdx:highIdx:sortDescriptors:] + 286
8 CoreData 0x0297e1b2 -[NSFetchedResultsController(PrivateMethods) _postprocessInsertedObjects:] + 402
9 CoreData 0x029841bc -[NSFetchedResultsController(PrivateMethods) _managedObjectContextDidChange:] + 1804
10 Foundation 0x02380c1d _nsnote_callback + 145
11 CoreFoundation 0x02bd6cf9 __CFXNotificationPost_old + 745
12 CoreFoundation 0x02b5611a _CFXNotificationPostNotification + 186
13 Foundation 0x023767c2 -[NSNotificationCenter postNotificationName:object:userInfo:] + 134
14 CoreData 0x028c0519 -[NSManagedObjectContext(_NSInternalNotificationHandling) _postObjectsDidChangeNotificationWithUserInfo:] + 89
15 CoreData 0x028f802b -[NSManagedObjectContext mergeChangesFromContextDidSaveNotification:] + 1579
16 Foundation 0x02395e9a __NSThreadPerformPerform + 251
17 CoreFoundation 0x02bdfd7f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
18 CoreFoundation 0x02b3e2cb __CFRunLoopDoSources0 + 571
19 CoreFoundation 0x02b3d7c6 __CFRunLoopRun + 470
20 CoreFoundation 0x02b3d280 CFRunLoopRunSpecific + 208
21 CoreFoundation 0x02b3d1a1 CFRunLoopRunInMode + 97
22 GraphicsServices 0x031e62c8 GSEventRunModal + 217
23 GraphicsServices 0x031e638d GSEventRun + 115
24 UIKit 0x0063cb58 UIApplicationMain + 1160
25 Nanopost 0x0000230a main + 170
26 Nanopost 0x00002255 start + 53
)
terminate called after throwing an instance of '_NSCoreDataException'
When I initialize the "NSFetchRequest", I set the "FetchBatchSize" to 20 (randomly):
[l_FetchRequest setFetchBatchSize:20];
But if I set the "FetchBatchSize" to 25:
[l_FetchRequest setFetchBatchSize:25];
... No more crashes on iOS4 and I don't know why and I want to understand this issue :) I don't think that this line is the real problem. Maybe it indicates another problem somewhere?
Thank you very much in advance for your answers!
Thomas
Is there a reason you are using a different context? I don't switch mine, and I have a pretty similar sounding app.
One thing you might compare to is this very handy CoreDataTableViewController:
http://www.stanford.edu/class/cs193p/cgi-bin/drupal/node/289
I use it and haven't had any issues (though I am not running in iOS 4). You might compare how you hooked up the fetchedResultsController.
One other point - do you have the catch-all breakpoint to push the debugger as soon as an exception is raised? If not, add it (breakpoints, + to add, "Add Exception Breakpoint" and keep defaults). That will put you into the debugger right on the line that raises the exception, which should be useful.
Good luck,
Damien