It’s a point of frustration for iPhone users whenever an application fails. What factors contribute to this failure? A few of them are programmer errors, sloppy threads handling, memory and processing power mismanagement, etc. Excluding programmers, also poor network connections can force an app to crash as well. So, an iPhone app Tester’s role becomes paramount in such situations to identify the reasons for crashes and in helping developers to fix them.
Crash reports and a Tester’s approach towards them:
When an application crashes on an iOS device, a “crash report” is created and stored on the device. Crash reports describe the conditions under which the application is terminated and are typically very useful for debugging issues in the application. If you are an iOS app developer, you should look at these crash reports to understand what crashes your application is experiencing before trying to fix them. So when testers face such crashes they have to collect these reports, console logs and attach with the bugs.
How a Tester extracts the crash logs without Xcode?
A manual tester may not have Xcode installed in his system, so let’s discuss how to get these logs without Xcode.
- Plug in the device
- Sync with iTunes
- Crash logs can be found in the following locations, depending on the platform
|Mac OS X||~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>|
|Windows XP||C:\Documents and Settings\<USERNAME>\Application Data\AppleComputer\Logs\CrashReporter\MobileDevice\<DEVICE_NAME>|
|Windows Vista or 7||C:\Users\<USERNAME>\AppData\Roaming\AppleComputer\Logs\CrashReporter\MobileDevice\<DEVICE_NAME>|
<USERNAME> is the user’s login name for the computer. <DEVICE_NAME> is the name of the iOS device, for example, “John’s iPhone”.
If an app is deployed in the App Store, then you will be able to see crash logs in iTunes Connect; but only if the affected customers have opted to send diagnostic and usage information to Apple.
Analyzing crash reports:
Crash reports contain stack traces for each thread of your application at the time execution halted. Instead of method or function names, known as symbols, it contains hexadecimal addresses and executable codes of your application or system frameworks to which they refer. So you have to map these addresses to the symbols, this process is called symbolication but you require Xcode for this. So I have given some exception codes below, which can be used to identify the type of crash log.
In the crash log there is a line that starts with the text Exception Codes: followed by one or more hexadecimal values. These exception codes are used to identify the crash logs. A few are given below for your view.
- The exception code 0xbaaaaaad indicates that the log is a stackshot of the entire system, not a crash report. These logs are accidentally created by users, and do not indicate an error. To take a stackshot, push the home button and any volume button.
- The exception code 0xbad22222 indicates that a VoIP application has been terminated by iOS because it resumes frequently.
- The exception code 0x8badf00d indicates that an application has been terminated by iOS because a watchdog timeout occurred, i.e. the application took too long to launch, terminate, or respond to system events.
- The exception code 0xc00010ff indicates the app was killed by the operating system in response to a thermal event. This may depend on the particular device on which the crash has occurred and the environment it was operated in.
- The exception code 0xdead10cc indicates that an application has been terminated by iOS because it holds on to a system resource (like the address book database) while running in the background.
- The exception code 0xdeadfa11 indicates that an application has been forced to stop by the user when the application became unresponsive.
In cases like this, extracting the exception codes without Xcode is impossible. However, you’ve some tools (free) using which it becomes easier to get the exception codes without the help of the Xcode.
Tools for extracting exception codes:
Other than the above method there are also some free tools which can be used to get crash reports. Some of them are:
Crashlytics site will prompt you to download a Mac application. This application will guide you through the process of configuring your iOS application to work with Crashlytics service. It will first ask you to pick an Xcode project on your disk. Next, it will install the Crashlytics framework, and finally, it will add a step to the building phase of your project. Now if any crash occurs in your application it will be updated to the backend of crashlytics. You can login and find these crash logs already symbolicated and understandable. This can also be integrated with bug tracking and project management tools like Jira, Redmine, Campfire PagerDuty and pivotal Tracker.
Bugsense setup is pretty similar to other platforms. create an account, create an application, download an SDK, include it in your project, and set the API key. This also displays the number of time a crash has occurred. The major difference between Crashlytics and Bugsense is that you have to upload the “.dsym” file manually in Bugsense. This can be integrated with Jira.
Setup is similar to Bugsense. This provides with contextual information which will be useful to find the root cause of a crash. Currently it has no third party integrations.
I strongly believe this post has given you some in-depth ideas on how to get crash reports and analyze them without Xcode. If you’ve some other tools used for extracting the exception codes than the ones listed above, kindly input via comments.