I intermittently get Crashlytics reports with the following error:
Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x0000000e
raw
libobjc.A.dylib
objc_msgSend + 5
1
UIKit
-[UICollectionViewUpdate _computeItemUpdates] + 1588
2
UIKit
-[UICollectionViewUpdate initWithCollectionView:updateItems:oldModel:newModel:oldVisibleBounds:newVisibleBounds:] + 254
3
UIKit
-[UICollectionView _endItemAnimations] + 6904
4
UIKit
-[UICollectionView performBatchUpdates:completion:] + 386
How can I debug this? The crash appears to be internal to a UICollectionView. Does this mean the crash is internal to an Apple SDK?
You can add a symbolic breakpoint with -[UICollectionViewUpdate _computeItemUpdates] as the value. Whenever that method is called, you'll be able to navigate the stack trace and (hopefully) see which line of your code is the last to be called before the crash.
The downside of this approach is you'll probably get a lot of pauses that are not followed by the crash, but it'll give you an idea of where it's coming from. Once you find the source of the crash in your code, unset the breakpoint and change a value or set something related to the cells until you can cause the crash to happen.
This is generally my approach to tracking down crashes from my crash reports from Flurry. Being you've ask this question half a year ago, if you found a solution to tracking down these types of bugs, I would appreciate it if you shared :)
Related
I only see this crash in Xcode > Window > Organizer > Crashes tab and not in Firebase Crashlytics.
It seems like it's only happening on iOS 13 so far and is one of the top 5 crashes in the app.
Also filed this in https://feedbackassistant.apple.com
I contacted Apple Developer support about this and got this answer:
In regards to what is happening in your crash logs, you definitely have a deallocated Zombie object that is being called causing this to crash. Notice the crashing thread in each of logs ends with Objective-C sending a message resulting in a EXC_BAD_ACCESS exception type.
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000010
Thread 0 name:
Thread 0 Crashed:
0 libobjc.A.dylib 0x00000001b6338fb0 objc_msgSend + 16
1 Foundation 0x00000001b69eb558 probeGC + 124 (NSMapTable.m:721)
2 Foundation 0x00000001b68fa2fc -[NSConcreteMapTable rehashAround:] + 208 (NSMapTable.m:1098)
3 Foundation 0x00000001b68fa1fc -[NSConcreteMapTable removeObjectForKey:] + 252 (NSMapTable.m:1141)
The crash signature that you are seeing is consistent with other known crash signatures I am tracking right now:
2 Foundation 0x00000001ad188d64 -[NSConcreteMapTable rehashAround:] + 204 (NSMapTable.m:1098)
3 Foundation 0x00000001ad188c68 -[NSConcreteMapTable removeObjectForKey:] + 248 (NSMapTable.m:1141)
4 UIKitCore 0x00000001b13d9484 _UIAnalyticsGatherMultitouchAnalytics + 632 (_UIMultitouchAnalytics.m:249)
I did some internal research on this issue and this is a bug right now in UIKit. Other applications are experiencing the same thing so please make sure to list as much information as possible in the bug report.
However, I don’t have any other information than what I see through apples bug reports.
Just two things I noticed:
This crash did so far occur under iOS 13.3.1 only.
This crash does not seem to be completely random, several crashes have the same reporter ID, so they are coming from the same user. This might mean that some setting their devices makes the crash more likely.
I have 198 crashes on Crashlytics for one issue and i cant seem to figure it out, the last last line of my code that it points to is a closing brace, i understand that the problem is somewhere else in the code, but i dont seem to understand the Error message as i cant find anything about it on the internet. Has anyone experienced anything related to _fatalErrorMessageNeverStaticString.
Crashed: com.apple.main-thread
0 libswiftCore.dylib 0x1024731b8 _fatalErrorMessageNeverStaticString (__hidden#23281_:179)
1 MyAppName 0x1010b95dc DetailTableViewController.viewDidLoad() -> () (DetailTableViewController.swift:124)
2 MyAppName 0x1010b99c0 #objc DetailTableViewController.viewDidLoad() -> () (DetailTableViewController.swift)
3 UIKit 0x18bb25a00 -[UIViewController loadViewIfRequired] + 1040
4 UIKit 0x18bb255d8 -[UIViewController view] + 28
.
.
.
I figured it out, pbodsk did point me in the right direction. It was an Optional Unwrapping. In Fabric, i clicked View all Sessions and then with the switch turned to Keys, it showed me the correct crash log at the top of the usual crash logs.
The _fatalErrorMessageNeverStaticString message wasnt clear which threw me off but to my understanding it was that Fabric wasnt clear about the Crash Info Entry or it thought there were multiple different messages. But the solution was the View all Sessions to see the correct log.
I have a crashgroup that I don't understand and which I did not manage to reproduce yet. Does anyone have a clue what is going on here? To me it look like there is a view that is created, and maybe deallocated right away? In fact I also often see reference to the init method of some of my views just before this stacktrace, But the views are varying so it seemes that I have this problem in many places of my app. :-(
Application Specific Information:
objc_msgSend() selector name: retain
Thread 0 Crashed:
0 libobjc.A.dylib 0x0000000182b81bd0 objc_msgSend + 16
1 Foundation 0x0000000183dd68e4 -[NSObject(NSKeyValueObserverNotification) willChangeValueForKey:] + 320
2 QuartzCore 0x0000000185bf3374 CA::Layer::set_delegate(objc_object*) + 68
3 UIKit 0x00000001881f6538 -[UIView _createLayerWithFrame:] + 576
4 UIKit 0x00000001881f5ff8 UIViewCommonInitWithFrame + 684
5 UIKit 0x00000001881f5ce8 -[UIView initWithFrame:] + 136
Is that fact that is says: objc_msgSend() selector name: retain some kind of clue? To me it look like retain is being called, but why should it crash then?
This is a memory management issue. You will need to replicate the conditions of the crash with Zombies turned on. Some object has vanished out from under its pointer, and Zombies will tell you what object it is.
The detail article on this kind of crash:
http://www.sealiesoftware.com/blog/archive/2008/09/22/objc_explain_So_you_crashed_in_objc_msgSend.html
I just received my first crash report from Crashlytics and am attempting to correct the issue. Unfortunately it is only with a line of code that runs on older devices so I can't test it on my iPhone 6.
The crash report from Crashlytics highlights two threads, the first reads:
Fatal Exception: NSInvalidArgumentException
-[CABasicAnimation altitude]: unrecognized selector sent to instance 0x17734440
While the second reads:
Crashed: Map Update :: NSOperation 0x1a839470
SIGABRT ABORT at 0x316a3dfc
The indicated line of code for both threads is:
let relativeAlt = mylocation.altitude - appDelegate.elevation
Where:
let mylocation = self.mapView.myLocation
let appDelegate = (UIApplication.sharedApplication().delegate as AppDelegate)
I'm trying to understand what I'm reading in the crash report. The way I see it the program doesn't understand the altitude reference made for some reason? This doesn't make sense to me since this crash seems to occur after that app has been running for several minutes without error, the highlighted line of code is run possibly hundreds of times before the app crashed. What is really happening here?
Additional Information:
Since writing, I have received additional crashes that I believe stem from the same issue:
Crashed: Map Update :: NSOperation 0x19fb2d50
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x11d077ca
Crashed: Map Update :: NSOperation 0x145ced50
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x81450a64
The first highlighted the following line in my code (I believe since I had worked on the app since this beta release and the line numbers have changed slightly):
self.lastLocation = (self.mapView.myLocation as CLLocation).coordinate
While the second crash just gave me:
libobjc.A.dylib
objc_msgSend + 5
The first of the new crashes (That provided a line of code) provided this report:
Thread : Crashed: Map Update :: NSOperation 0x19fb2d50
0 libobjc.A.dylib 0x3105c708 objc_release + 7
1 FlightTracker 0x000ba830 FlightTracker.MapViewController. (locationManager (FlightTracker.MapViewController) -> (Swift.ImplicitlyUnwrappedOptional<ObjectiveC.CLLocationManager>, didUpdateLocations : Swift.ImplicitlyUnwrappedOptional<Swift.Array<Swift.AnyObject>>) -> ()).(closure #1) (MapViewController.swift:168)
2 Foundation 0x244ce0fd __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 8
3 Foundation 0x24438fc5 -[NSBlockOperation main] + 148
4 Foundation 0x2442b845 -[__NSOperationInternal _start:] + 768
5 Foundation 0x244d0a57 __NSOQSchedule_f + 186
6 libdispatch.dylib 0x315ad5d9 _dispatch_queue_drain$VARIANT$mp + 948
7 libdispatch.dylib 0x315ad0a9 _dispatch_queue_invoke$VARIANT$mp + 84
8 libdispatch.dylib 0x315af0d3 _dispatch_root_queue_drain + 330
9 libdispatch.dylib 0x315b01fb _dispatch_worker_thread3 + 106
10 libsystem_pthread.dylib 0x31720e25 _pthread_wqthread + 668
Probably not your problem, but I just had a SIGABRT that was driving me nuts (that's how I ended up looking at this question) and I'll post my solution in case it helps some future S.O. spelunker.
In my (iPad, not that it matters) app, you can push a button that results in the creation of a not-full-screen UIViewController which contains a UITableView, and this viewController is presented via UIPopoverController.
In my case I had a screw-up in my loading of the tableView items which, at the time of creating the tableView cell I ended up trying to add a null value into a dictionary. (It's a long story, having to do with an infrastructure class that expects the data to be in a certain format.)
Anyway, attempting to access newViewController.view caused the SIGABRT on that line, with no clue that the problem was related to filling the tableView cell. Nothing tableView-related was evident in the stack trace, so it took me quite a while to narrow things down. I eventually just guessed "maybe it's the tableview" and disconnected the IBOutlet and delegate/dataSource to see if the crash went away.
...And it did. Which lead me down the path of finding the real problem.
Anyway, that's my story. Hope it's helpful to someone.
Due to the lack of a full/proper crash report and the lack of more code and architecture, the following is an assumption using the little bits of information that are available.
You are accessing a variable in a background thread (NSOperation queue) that got released on another thread and now isn't available any longer, so the pointer shows to some other random object in the memory. And that random object surely has no idea what to do with the altitude message which is then causing the crash.
You have to make sure that all variables used in the background thread, are available and not released in another thread.
Wow, I just had another "impossible to track down" solution to this that was driving me bonkers.
Earlier in the day, I'd done a major refactor as some of the objects in my game had names like RFCFoo and some were like RfcBar and I wanted to standardize the capitalization.
So I used XCode's Refactor->Rename... tool, and it worked great, except for one thing:
It failed to rename one specific .xib file, which remained as "RFCBlahBlah.xib" when I was trying to load it as "RfcBlahBlah.xib"
Again, I hope this proves useful for some future SO searcher.
I am getting a crash in the app with the following stack trace-
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x39dfa66a objc_release + 9
1 libobjc.A.dylib 0x39dfb0d7 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 358
2 CoreFoundation 0x2f4a6c69 _CFAutoreleasePoolPop + 16
3 CoreFoundation 0x2f53c1cb __CFRunLoopRun + 1306
4 CoreFoundation 0x2f4a6f0f CFRunLoopRunSpecific + 522
5 CoreFoundation 0x2f4a6cf3 CFRunLoopRunInMode + 106
6 GraphicsServices 0x343ff663 GSEventRunModal + 138
7 UIKit 0x31df216d UIApplicationMain + 1136
8 Batted 0x0009db07 main (main.m:16)
The crash occurs when zombies are not enabled in the Scheme's diagnostics options. However, when I enabled it the crash doesn't occur.
I have read some of the other Q&A regarding this, and all of them seem to advice that once this behavior is seen, enable the zombies and run the Zombie Profile Instruments on the Simulator.
I tried that, but Instruments doesn't seem to indicate anything wrong and the app works.
Any clue to what else can be done here to root-cause this issue?
I am using XCode 5.1 with iOS 7.1 in Simulator.
UPDATE 1
Found the offending code causing the problem but I am still not sure why it is causing the problem.
I am using CoreData, and in subclass of the NSManagedObject, I have -
- (void)willTurnIntoFault;
{
[super willTurnIntoFault];
if ([self observationInfo])
{
BNLogInfo(#"%# has observers:\n%#", [self objectID], [self observationInfo]);
}
}
In the above code, [self observationInfo] is the offending line.
When the app starts up, I loop over some of the NSManagedObjects in an enumeration block and set some property on it, which in turn fires the willTurnIntoFault method. Once the enumeration block completes, the crash happens.
The mystery is that the crash doesn't happen inside this method, but without this method subclassed everything runs fine.
The Q&As say to enable zombies (or run under the Zombies instrument) because a zombie often causes this sort of error.
But it's not the only cause.
Your program is corrupting the heap. Most likely it's overwriting the isa pointer (the class pointer) in some object that's in the autorelease pool, so when the run loop drains the autorelease pool, objc_release tries to dereference the bogus isa pointer and crashes.
Enabling zombies can mask an error like this because, with zombies, the runtime never actually frees objects. This means you end up with lots of parts of the heap that don't get used (unless you try to send a message to a zombie), so they never cause trouble if you corrupt them.
These sorts of crashes can be very difficult to debug, but there's a tool called “guard malloc” that sometimes helps. From the menu bar, choose Product > Scheme > Edit Scheme. Click the Run action in the list on the left. Then click the Diagnostics tab. Turn on the “Enable Guard Malloc” option. Then try to reproduce the crash. Guard malloc will detect certain types of heap corruption immediately and stop the program on the corrupting instruction.