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.
Related
I have a symbolicated crash log from Xcode with the following lines:
3 Foundation 0x185a20a1c -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 112 (NSException.m:152)
4 UIKit 0x18a31b044 -[UISlider _setValue:minValue:maxValue:andSendAction:] + 224 (UISlider.m:1396)
5 MyApp 0x10013cea8 -[RecordingPlayer updateRecordingControls:fullUpdate:] + 284 (RecordingPlayer.m:1448)
I can tell from the last line that the app is crashing when I set the maximumValue property of a UISlider. And I can guess from the other two lines that my app is trying to set that property to an invalid value. But is there any way to find out exactly what assertion failed?
If I could find an explanation like "maximumValue must be greater than 0," that would help me understand where in my code this bad value is getting calculated.
Unfortunately, I can't reproduce the problem on my own devices, so I can't debug to inspect the values when the crash occurs.
I'm running corona SDK with a chartboost plugin, and I'm experiencing crashes about 20% of the time at startup, when I try to initialize the plugin (which I can't edit, I don't have the source).
Here's the symbolicated crash report: http://pastebin.com/id1AsjmN
I've been reading up a little on how to make sense of these crash reports, and from what I understand, these two frames in the main thread:
9 CoreFoundation 0x295d9008 +[NSException raise:format:arguments:] + 100
10 Foundation 0x2a2d8bc4 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 88
Are the most critical to understanding my problem. How can I understand what these lines mean? The "object:file:lineNumber:description:" and "raise:format:arguments:" business seems almost cruel, because I feel like those should be filled in with information that would help me -- what class, and line number we're talking about. Am I right? Are these placeholders in the error message? What am I not grokking here? Is there ANY way of knowing where this error came from?
It's not symbolicated crash log. To be more precise, partially symbolicated.
9 CoreFoundation 0x295d9008 +[NSException raise:format:arguments:] + 100
10 Foundation 0x2a2d8bc4 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 88
11 UIKit 0x2d00946e -[UINib initWithNibName:directory:bundle:] + 158
12 UIKit 0x2d00955c +[UINib nibWithNibName:bundle:] + 56
13 splashboardd 0x000bee8c 0xbc000 + 11916
Somewhere in your splashboard code something is called (0x000bee8c 0xbc000 + 11916 - not symbolicated). This calls +[UINib nibWithName:bundle:], which calls -[UINib initWithNibName:directory:bundle:], which causes your crash.
Google for How to symbolicate crash log and when you'll succeed, 0xbc000 + 11916 will be replaced with class name, method name, line number, ... That's the place where the problem is. Also that's the reason why you should keep debug symbols for your app as well. To be able to symbolicate it.
Also sometimes there's useful info in console as well. Additional messages, which can help you with debugging.
I'm trying to integrate some third-party SceneKit code into my app, and I'm experiencing a mysterious crash. Oddly, the crash gives no error or log in Xcode, and the stack trace is just "UIApplicationMain". No helpful info there.
The code works in the third-party app where I got it and I've copied it wholesale, so I know it must be some delegate call or some framework that I haven't included, etc. But this is my first experience with SceneKit so I'm having trouble closing in on what it could be.
The crash happens during an event where the user taps on the screen and a new 3D object is added to the scene. I've breakpointed all the associated methods, and the crash seems to be happening in the in-between time, presumably the internal SceneKit functionality, so I can't pinpoint it.
My Crashlytics report, though, did pick up some info, which I have included here:
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x00981ea8 _objc_empty_cache
1 SceneKit 0x015e0273 __28-[SCNPhysicsBody _setOwner:]_block_invoke + 214
2 SceneKit 0x016b05b5 C3DTransactionFlush + 2014
3 CoreFoundation 0x00bff86e __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30
4 CoreFoundation 0x00bff7b0 __CFRunLoopDoObservers + 400
5 CoreFoundation 0x00bf51ea __CFRunLoopRun + 1226
6 CoreFoundation 0x00bf4a5b CFRunLoopRunSpecific + 443
7 CoreFoundation 0x00bf488b CFRunLoopRunInMode + 123
8 GraphicsServices 0x043042c9 GSEventRunModal + 192
9 GraphicsServices 0x04304106 GSEventRun + 104
10 UIKit 0x01b99106 UIApplicationMain + 1526
11 SW LiveSheet 0x0007888a main (main.m:14)
12 libdyld.dylib 0x04e61ac9 start + 1
A search of my project finds no examples of SCNPhysicsBody _setOwner:, so I'm assuming that is an internal SceneKit method?
Does anyone know what might be causing a crash like this? I'll include any methods that might be relevant (if you tell me what they might be), but the series of methods to create the object is very long, so it didn't seem productive to blindly copy it all here. Plus, as I said, the crash seems to be happening "between the methods" anyway.
Does anyone recognize this error? Or are there any common "getting started with SceneKit" mistakes that I might be making, that could lead to this? I know the code works because it works in the other project, it's just a matter of what got lost in translation. Also, the scene does load successfully before the tap begins the process of adding the new object.
Can anyone point me in the right direction? Even just an idea of where to investigate would be appreciated.
Thanks for helping out a SceneKit newbie!
Weirdly, the answer ended up being just running the app on a device. I never could figure out what was wrong in the Simulator, but as soon as I tried running it on a device, it worked without changing anything!
Frustrating, to try to hunt down a solution for such a weird thing, but hopefully this will help anyone who experiences something similar.
If you're doing something with SceneKit and you're getting a bizarre error like this, try running it on a device before you tear too much of your hair out.
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 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 :)