Reading Crash Logs

This post will list the steps you need to take to read a crash log after receiving the crash log file.  This assumes you are using the same Xcode (6+) that you used to Archive the app.

1. Connect your iOS device.
2. Open Xcode
3. In the menu, go to Window->Devices
4. Select your iOS device and click on the View Device Logs button.
5. Select the "All Logs" tab.
6. If you crash log file does not have the .crash extension, rename it to have a .crash extension.
7. Drag the file into the device's log window.  Specifically, the left column.
8. Wait a minute or so until the list of logs shows the log you dragged in.
9. When your log shows up, right-click on your log and select Re-Symbolicate Log.
10. Once Re-Symbolicating is done you will have a readable crash log.

This information has been compiled from the Stack Overflow answer and comments:

http://stackoverflow.com/questions/25855389/how-to-symbolicate-crash-log-xcode

Location of Sqlite DB in Simulator

In Terminal, navigate to:
~/Library/Application Support/iPhone Simulator

Then it's your os version number and find the folder for the app.  Your App data along with the sqlite database is in the Documents folder.

Does not implement methodSignatureForSelector - trouble ahead

In iOS if you get the following error:

does not implement methodSignatureForSelector: — trouble ahead

It's most likely that one of your classes does not inherit from NSObject.  An easy fix is to changes this:

@interface MyClass

to this:

@interface MyClass : NSObject

iOS 5 seems to be able to handle when a class does not inherit from NSObject.  iOS 4 and lower will throw this error.

Mobfox leaks

After hours and hours of running Leaks instrument and pulling out my hair on my own project, I finally re-ran Mobfox's MobFoxDemoAdv project with Leaks and found that it does leak.  The first time for some reason it didn't, this time, it did.  I ran it for 4 minutes and in that timespan it leaked a couple times.

From Device Crash Log to Stack Trace

Update:  If this doesn't work for you anymore, try this:
http://iphoneidoit.blogspot.com/2016/03/reading-crash-logs.html

There seems to be a few ways to get the stack trace from the device logs.  One way is a 3rd party solution where you implement their API and they can send you a nice stack trace.  Another way is by using symbolicate, which seemed out of date.

Until I get around to using the 3rd party solution I use the atos command.  Below is a step by step in how you can get a stack trace from your device's crash logs.  You will need the build that caused the crash and the crash log.  Note, there may be an easier way to do this, I just haven't looked more after finding this method.

A typical unreadable crash log contains something like this:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)

Exception Codes: KERN_INVALID_ADDRESS at 0x00000008

Crashed Thread:  6

Thread 0 name:  Dispatch queue: com.apple.main-thread

Thread 0:

0   libicucore.A.dylib            0x318fb3c8 0x31897000 + 410568

1   libsystem_c.dylib             0x3310850a 0x330bb000 + 316682

2   libicucore.A.dylib            0x31971744 0x31897000 + 894788

3   libicucore.A.dylib            0x318a59b8 0x31897000 + 59832

4   libicucore.A.dylib            0x3189fe98 0x31897000 + 36504

5   CoreFoundation                0x34c6b042 0x34bef000 + 507970

6   CoreFoundation                0x34c2f14a 0x34bef000 + 262474

7   Foundation                    0x320d4020 0x320aa000 + 172064

8   Foundation                    0x320d3efe 0x320aa000 + 171774

...

For starters, turn that into this:

0x318fb3c8 0x31897000 + 410568 0x3310850a 0x330bb000 + 316682 0x31971744 0x31897000 + 894788 0x318a59b8 0x31897000 + 59832 0x3189fe98 0x31897000 + 36504 0x34c6b042 0x34bef000 + 507970 0x34c2f14a 0x34bef000 + 262474 0x320d4020 0x320aa000 + 172064 0x320d3efe 0x320aa000 + 171774

Just take out the first two columns and the carriage returns.  Save this to a file in some easy to type directory like ~/memory_addresses.txt

Get the Build

Get the binary where the error was generated from.  It should have a filename of something like mycrashingapp.app.

ATOS command

Navigate to where the app binary file is and type in the following, replace the bold with your specific info.

atos -o mycrashingapp.app/mycrashingapp -arch armv6 -f ~/memory_addresses.txt > stack.txt

stack.txt should now contain some useful information on where the crash happened.

Beware of Caching

I recently found that doing a "Clean All" in Xcode is not enough to make a clean build.  I removed an image from the project thinking it wasn't needed.  I did a "Clean All", rebuilt, and everything looked fine in the simulator.  I installed a fresh build on the device, and saw that an image was missing.  I went back to Xcode, did another "Clean All" rebuilt, and it still looked fine in the simulator.  I then deleted the app from the simulator, exited the simulator and rebuilt.  Only after all that did I see the missing image in the simulator.

iPhone Simulator Data Location

The iPhone simulator stores the library folder.
~/Library/Application Support/iPhone Simulator/User/
or
~/Library/Application Support/iPhone Simulator/[OS version]/Applications/[appGUID]/
depending on the SDK.

To see this exact path you can use the following code:

NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];


Using the Debugger in XCode

Using XCode 3.2.1:

STARTING UP THE DEBUGGER:

To start up your application in debug mode, click the Breakpoints icon on the Project Toolbar. You will notice that Build and Run turns into Build and Debug.

VIEWING DEBUGGER/CONSOLE WINDOWS:

To open the Debugger window when debugging, go to Run > Debugger. To see the Console, same thing: Run > Console. You can also open these windows by clicking the relevant icons on the Debugger strip.

STACK TRACE:
Add 'objc_exception_throw' as a breakpoint via Run > Debugger > Show Breakpoints.  When you run your app on the simulator in Debug mode and an exception occurs anywhere in your code, the app will stop and you can usually view a stack trace of your code.  This is because the debugger is now set up to catch 'objc_exception_throw'.

EXPRESSIONS(I.E. WATCHING VARIABLES):
Also, if you want to see what certain variables are, you can use the Expressions window via Run > Show > Expressions.

STATIC ANALYZER:
Select Run > Build and Analyze to run the Static Analyzer. This will uhhh "analyze" your code for things like possible memory leaks and other possible errors that the compiler would not necessarily catch(i.e. setting a variable to zero, and then dividing by that). NOTE: this found the memory leak that is/was in getDeckCount().