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).
Related
I have completed developing a Swift application using iOS SDK 8.1 and it is now being tested by external testers via TestFlight as beta. Recently, I have received a crash report via Crashlytics with the following stack trace:
0 libobjc.A.dylib objc_msgSend + 28 setRefreshControlState:
1 libdispatch.dylib _dispatch_call_block_and_release + 24
2 libdispatch.dylib _dispatch_client_callout + 16
3 libdispatch.dylib _dispatch_after_timer_callback + 92
4 libdispatch.dylib _dispatch_client_callout + 16
5 libdispatch.dylib _dispatch_source_latch_and_call + 792
6 libdispatch.dylib _dispatch_source_invoke + 288
7 libdispatch.dylib _dispatch_main_queue_callback_4CF + 424
8 CoreFoundation __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
9 CoreFoundation __CFRunLoopRun + 1492
10 CoreFoundation CFRunLoopRunSpecific + 396
11 GraphicsServices GSEventRunModal + 168
12 UIKit UIApplicationMain + 1488
13 opsgenie AppDelegate.swift line 0 top_level_code
14 opsgenie AppDelegate.swift line 0 main
15 libdyld.dylib start + 4
I could not replicate the issue neither on my own device, nor on simulator and this crash has happened only once in three weeks. I have no idea about what may cause this crash and what this crash report means. I have also analysed my custom Crashlytics logs which are generated, however, everything seems normal and I still have no idea about the problem. I know it is nearly impossible to understand the problem by only having this stack trace on hand, but any recommendation/idea would be very useful.
you are using pull to refresh , while the content is loading user is going to another view hence the crash.try to replicate it on a slow connection while doing pull to refresh.you can make sure you handle startRefreshing, endRefreshing methods properly
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?
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'm running my ios app in ipad 1, the following crash happen sometime while app is running, i don't know where the crash happen. This mostly happen in ios 5.1.1 . Here the crash log,
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xf0000008
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x3387ef78 objc_msgSend + 16
1 UIKit 0x333ffa3a -[UIViewController unloadViewForced:] + 254
2 UIKit 0x335473a6 -[UIViewController purgeMemoryForReason:] + 58
3 Foundation 0x3507a4f8 __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 + 12
4 CoreFoundation 0x35c2c540 ___CFXNotificationPost_block_invoke_0 + 64
5 CoreFoundation 0x35bb8090 _CFXNotificationPost + 1400
6 Foundation 0x34fee3e4 -[NSNotificationCenter postNotificationName:object:userInfo:] + 60
7 Foundation 0x34fefc14 -[NSNotificationCenter postNotificationName:object:] + 24
8 UIKit 0x335120e6 -[UIApplication _performMemoryWarning] + 74
9 UIKit 0x335121e0 -[UIApplication _receivedMemoryNotification] + 168
10 libdispatch.dylib 0x33ffb252 _dispatch_source_invoke + 510
11 libdispatch.dylib 0x33ff8b1e _dispatch_queue_invoke$VARIANT$up + 42
12 libdispatch.dylib 0x33ff8e64 _dispatch_main_queue_callback_4CF$VARIANT$up + 152
13 CoreFoundation 0x35c332a6 __CFRunLoopRun + 1262
14 CoreFoundation 0x35bb649e CFRunLoopRunSpecific + 294
15 CoreFoundation 0x35bb6366 CFRunLoopRunInMode + 98
16 GraphicsServices 0x33951432 GSEventRunModal + 130
17 UIKit 0x3338ecce UIApplicationMain + 1074
18 MY Game 0x00079a90 0x75000 + 19088
19 MY Game 0x00079a50 0x75000 + 19024
As i understand from crash log, crash not happen due to my code. It's due low memory. Is that correct? How to find where the crash happen? Any suggestions.
As i understand from crash log, crash not happen due to my code. It's due low memory. Is that correct?
No, that's not correct.
Low memory is being reported, but your view controller is not responding properly. The most common cause of this is a retain cycle - see UIViewController purgeMemoryForReason: Crashing on iOS 5. In that answer, the retain cycle is in SVPullToRefresh , but yours could be elsewhere. The most common cause of retain cycles is not setting a delegate property to weak.
Once you figure out where the issue is, you can set breakpoints in viewDidUnload and ``didReceiveMemoryWarning`, simulate a memory warning, and step through your code to find the error.
Symbolication
Additionally, this crash report isn't symbolicated. Typically you'll want to symbolicate your crash report first. For example, see these lines:
18 MY Game 0x00079a90 0x75000 + 19088
19 MY Game 0x00079a50 0x75000 + 19024
In this case, as pointed out by Kerni, those two will just show start and main, so they won't help you in this instance. But generally, you should symbolicate your crash reports. (Search for "Xccode symbolicate crash logs" if you don't know how to do this.)
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?