How crash reporting tools really work - ios

I know there are many crash reporting tools available in the market to collect crashes from the real devices. I would like to know how a crash reporting tool really collects its data?. Does it collect a crash report from the operating system once the crashed application launched again? or Does iOS allows the crash reporter to collect the data as soon as the app is crashed?.
It will be really great if somebody can explain what happens after an app is crashed or point me to right place.

System crash logs are located at /private/var/mobile/Library/Logs/CrashReporter/ and (as far as I know) can't be accessed by the app directly. Most crash reporting tools will try to catch crashes and generate their own crash reports which will get stored locally and sent to a server for symbolication and processing.
You can take a look at the source for KSCrash, an open source crash reporting tool, to see how crashes are caught/stored/reported.

Related

Identify Crash log in iOS

We have used several 3rd party crash logs in past like crittercism, Flurry, crashlytics etc. There're some crash logs in which we are not able to get exact crash point. So, do we have any tool available which provides exact crash point ?
OR which is best 3rd party crash log tools in iOS ?
Depending on the type of crash, stack traces may not contain any of your apps code, which is perfectly fine.
Especially when dealing with memory issues, the crash will happen somewhere completely different than where the bug in your application is. You will have to check for the Exception Type information in the crash log and then go from there.
The following documents can help you understand crash reports better:
https://developer.apple.com/library/ios/technotes/tn2151/_index.html
http://www.raywenderlich.com/23704/demystifying-ios-application-crash-logs
You should also use the tools Xcode provides to make sure there are no easy to detect bugs by using the Instruments Leaks tool, use the Analyze build feature in Xcode, or the Address Sanitizer check in Xcode 7.

Why is restart needed to send crash log on iOS?

With a custom crash reporting system (like the ones specialized at Ask the user to send crash log after crash on iPhone) to send the log, the app needs to restart. Why? Isn't there a possibility to send it during the custom exception handling? Or is there a crash reporting system that doesn't need to restart the app?
When a crash occurs the app is in a highly unstable state. So a crash reporting library can not do anything since even allocating memory at crash time may cause way more damage. So crash reporting SDKs can only use so-call async-safe C methods to collect all crash data. Any Objective-C code can not be processed either and also the iOS networking stack can not be used.
Please also note that exceptions are just one example of app crashes in Objective-C, there are also crashes triggered by low-level BSD signals. Both types mean that the app is in a highly unsafe and unstable state and as little code as possible should be invoked at crash time.
So this would require a rewrite of most of the networking frameworks to be able to send data out at crash time, and this may even not be possible to do in a safe way. That is why all proper crash reporting SDKs don't do anything like that.
In addition, on iOS it is not possible to create another process which could send the data in the background, so the only safe and possible solution is to send data the next time the app starts.
Now this has another conclusion that crashes that happen early on app startup might never be sent since the app is crashing before or while it sends. Some SDKs provide mechanisms to handle that scenario which most likely requires changes in your app startup code.
Since you app crashed there is no process running any more that you app controls, thus you can not start a new process to send the report.
Any code in the crash handler only has limited time to save what ever made you app crash before iOS kill whole app and removes it from memory.
When you restart you app the crash reporter formats the crash report and sends it. This can only be down when the when you app is active.

Capturing and sending crash logs to the server

If there is a crash for an application, can I capture the crash logs and send it to a server right after the crash. I guess my question really is if the app crashed can I use the network api to send some data to the server.
Lots of services out there to do this... HockeyApp & TestFlight spring to mind.
Update: HockeyApp has just released a Mac Application 'HockeyCoach' to allow you to view crash reports within a native App, with awesome functionality like viewing the source code referenced in the crash log etc...
I highly reccomend you check it out: http://hockeyapp.net/releases/hockeycoach/
Yes, there are several solutions that provide this functionality. One of them that I'm intimately familiar with (and works very well) is Apigee's Mobile Analytics (http://apigee.com/docs/enterprise/content/analyze_apps).
One of the important points for dealing with crash logs is to save a copy of your .dSYM. This is needed to symbolicate the crash log.
Try using Crashlytics. Extremely simple to incorporate into app and is completely free.

Is there a way to have our own app to upload its crash repot?

Not sure if that is possible. But what happens is, sometimes our app randomly crashes. We don't know what exactly the problem is. Is there a way for us to get the crash report off user's iphone? By code, or by another app?
Thanks.
You can inject a third party code in your app, which would basically save your crash reports and thereafter you can use them for analysis. The way we do is capture any crash logs and upload them to the app server, which uses the info to display through a user-friendly web Interface (access controlled for admin purposes).
A great open source Crash Reporter library can be found here https://github.com/kstenerud/KSCrash
It's the user who decides from Settings > General > About > Diagnostics & Usage whether to automatically send crash reports or not.
You can also use a third party component to get detailed information about crash events, for example Crittercism.
If you're interested in 3rd party services for crash reporting for iOS it's hard to go past Crashlytics. Very fast crash reporting, simple installation, great response times to queries.
I'd also mention the TestFlight SDK, which is free and easy to use, and allows you to gather crash reports easily from all your testers, and also do remote logging and other stuff. I used it on a location based app I was working on a while ago, and it was very helpful with debugging

Including custom data into iOS crash dumps

Hello Stack Overflow !
A simple question for you : is it possible to embed custom error data into automatically generated iOS crash dumps I get from my users when my app crashed on their device ?
For example : My SQlite database won't operate for some reason (say, the database file is corrupted).. I cannot recover from this error, so I throw an exception, and embed in the exception the detailed sqlite error message. The problem is, the crash dump of the application won't contain the exception message, so it's not easy to know under which conditions the application crashed.
Does anyone know a way to put things into the crash dump report ? Or do you have any other recommended way of reporting production crashes to the developper ?
Thanks !
No, you cannot ad your own data into the crash reports. It is also not possible to access iOS generated crash reports automatically because of the sandbox.
So my suggestion is as follows:
For logging your own data, use Cocoalumberjack. It is much faster than NSLog or other logging frameworks out there and has an option to log your messages into a file. Now when an exception occurs, or whenever else you want to, log that into a file. But if your app crashes right at a point where you add something into a log file, it most likely will be missing, since the app crashed the very same moment.
So its rather impossible to safely catch the exact SQL statement. But the crash report should give you enough information to understand what is happening, with the addition to what you logged of being done before. E.g. you could log the search string used in the SQL way before the SQL is being executed.
In general try not to log too much.
For catching crash report you should nothing else than a solution based on the open source framework PLCrashReporter, which can safely catch crashes, also when you app is already in the app store! Exception catching is not recommended, check this article to see why!
iTunes Connect offers you to view some crash reports too, but it takes up to 2 weeks to see some, but by far not all as e.g. pointed out by the Camera+ developers. So you better use your own solution.
PLCrashReporter will send you standard apple formatted crash reports, ready for symbolication, so you know where the crash happens in your code, including line numbers.
Some solutions based on PLCrashReporter are:
QuincyKit: Open Source client + php server, basic crash grouping, symbolication can be automated from your mac (I am the developer of this)
HockeyApp: Paid service, uses QuincyKit client, advanced crash grouping, symbolication fully done on the server (I am on of the developers of this)
Bugsense: Free service, symbolication announced as premium feature
AppBlade: Paid service, symbolication unknown
Crashlytics: Private beta, unknown features, their solution seems to be based on PLCrashReporter
The proposed solutions either allow sending the data automatically on the next startup or by asking the user if he/she agrees to send.
Disclaimer-as-per-the-faq: I am a developer for AppBlade.
AppBlade allows you to send custom parameters along with symbolicated crash reports as of December 2012.
Check it out! http://blog.appblade.com/news/2012/12/appblade-sdk-update-sessions-and-queues/

Resources