Including custom data into iOS crash dumps

Question

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 !

Grisette

Answer 1

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:

1. 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.

2. 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

3. The proposed solutions either allow sending the data automatically on the next startup or by asking the user if he/she agrees to send.

Offence

Minor correction: BugSense currently provides symbolication on the device. – Petrolic

Thanks Nick. That is new since today I guess :) So that means without line numbers and you require the symbols in the app binary? – Offence

Exactly right :) Symbolication became available when I took over iOS development at BugSense, so it's been there for a while. It doesn't work perfectly and line numbers and file info are missing. I recently found that some builds symbolicate even with some "stripping" options on and I'm trying to figure out why that is... – Petrolic

To my knowledge they provide symbolication on the server showing line numbers without requiring the symbols to be part of the application since some time. But as far as I know (by looking at reports posted here in StackOverflow) they only present the main thread when it is crashing and don't offer Last Exception Backtraces, which is important since exceptions get re-thrown into the next run-loop and the stack trace then is not where the crash actually happened. Please note I am member of the competitor product HockeyApp and haven't looked at it in detail lately. You need to check. – Offence

Great answer, You said "so you know where the crash happens in your code, including line numbers". How do u get the line number, I have never seen the line number or class name in any of my stack traces? – Homothallic

Crash reports need to be symbolicated. Which is done with the dSYM package that is generated next to the app binary. It contains a DWARF binary which contains all information needed to translated the memory addresses in the stack traces into class names, methods and line numbers. – Offence

I am a developer for AppBlade. To update your answer, AppBlade does currently support crash symbolicating. And you can send custom parameters with it, too! Source : blog.appblade.com/news/2012/12/… – Farriery

Answer 2

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/

Farriery