Get previous run, crash logs on iPhone

Question

I trying to write a a crash report feature that when you launch the app after a crash, it will offer to send the crash report to the server. I can't find how to get the crash log within the app. I saw there is a framework that doing so (PLCrashReporter), however this framework is large and I don't need most of it's features.

Does anyone knows how to simply access the log?

Thanks, Guy.

Answer 1

I had this similar issue and the PLCrashReported seemed too complicated for what I wanted to do. Note that you can't access the crash report generated by Apple, the PLCrashReport generates it's own reports and store them in the user's cache folder.

Eventually, I used the following example: http://cocoawithlove.com/2010/05/handling-unhandled-exceptions-and.html

it's very simple and easy to use, just register exception and signal handlers using:

NSSetUncaughtExceptionHandler(&HandleException);
signal(SIGABRT, SignalHandler);
signal(SIGILL, SignalHandler);
signal(SIGSEGV, SignalHandler);
signal(SIGFPE, SignalHandler);
signal(SIGBUS, SignalHandler);
signal(SIGPIPE, SignalHandler);

and get the stack trace using the backtrace method in UncaughtExceptionHandler class.

Answer 2

There are a bunch of (SAAS) E2E solutions that you may be very happy to know.

Very very simple to integrate into your application

Have Fun...

1. crashlytics (Free and my preferred)
2. hockeyapp
3. bugSense
4. Crittercism

In our days you may use the built-in crash reports (iOS & Android)

1. iOS (Itunes connect) - Viewing Crash Reports
2. Understanding Crash Reports on iPhone OS
3. Reading Android Market Crash Reports

Answer 3

I guess I don't have the karma to add a comment to Nimrod Gat's answer, so I have to provide my follow-up here. I'll try to make it worthy of a standalone answer.

It's very, very difficult to write a safe, correct, and reliable crash reporter, especially one that runs directly in-process. The code referenced in Nimrod Gat's answer is not correct and honestly, that blog post should be retracted. Signal handlers must only run async-safe code, and that code isn't async-safe:

http://www.cocoadev.com/index.pl?SignalSafety

Crash handling is even more complicated than normal signal handling, because that you can't expect the process to continue to run successfully after your signal handler returns.

It's tempting to think you can just hack together a simpler solution, and it will work some of the time, but there's a good reason people like Google's engineers have thousands of LoC dedicated to reliable crash reporting:

http://code.google.com/p/google-breakpad/

On iOS, you should just use PLCrashReporter. On other platforms (such as Mac OS X) you should use Google Breakpad. There's no point in re-inventing this wheel unless you're going to do it not only correctly, but better than what already exists.

Answer 4

Maybe a better solution will be to use a fully specialized end-2-end solution/service? Such as http://apphance.com. It is currently in closed beta testing phase, but you can ask for participation and we'll get back to you pretty quickly. The only thing you need to do is to register for an API key and embed a small framework library into your app (or .jar file in android). Then you have remote access not only to crashlogs but also to a debug logs generated by the application - which makes it much more useful. It is for now targeted to be used during testing, but there will soon be a lite version that you will be able to embed into app-store-released application.

Inside the framework we are doing all the magic of plugging-into the apple's framework and getting the crashlog information, decoding stack traces, even handling out-of-memory cases. All the comments by @nupark hold very much true: We spend countless hours on making it works seamlessly - thread-safeness, making sure that we can do the job of saving everything within the time required by Apple's framework before your app get finally killed, getting stack trace from out-of-memory case (that one was really difficult). The same for android - we've done some clever tricks there to make sure it's really working fine.

Disclaimer: I am CTO of Polidea, company which is behind apphance and co-creator of the solution.