SIGSEGV SEGV_ACCERR Crash Reports - What to do?

Question

I've just released an app on the AppStore with Crittercism crash reporting and I've been getting quite a few crash reports pertaining to a SIGSEGV error. Crittercism gives me a StackTrace and a few handy details about usage statistics, etc. however, I'm still befuddled by these symbolized stack traces. I have a few questions in general about this kind of thing -

1. Many of the classes and methods in the Stack Trace are not even used in my app (to my knowledge), which leads me to believe that these crashes are due to private APIs from Apple. Take a look at the Stack Trace near the bottom of this question. How can I tell what's crashing my app if all of the methods and classes in the crash report are not directly implemented in my code?

2. What do the + signs with numbers at the end of each line in the crashed thread stand for?

3. Most Q/A on StackOverflow that ask about SIGSEGV crashes say that they are caused by memory leaks or problems, however how can I have a crash because of a memory problem if I'm using ARC in my iOS project? Isn't ARC supposed to manage all of those things for me?

4. What should I do if I can't replicate the error / crash?

5. Is there any way to really read a StackTrace? IS there anything in general that would be helpful for understanding what is happening?

Here is the StackTrace from the Main Thread Crash Report from Crittercism that this question pertains to:

Thread: Unknown Name (Crashed)
0     UIKit                                 0x37307a22 -[UIView(CALayerDelegate) actionForLayer:forKey:] + 138
1     QuartzCore                            0x38fdfff7 -[CALayer actionForKey:] + 75
2     QuartzCore                            0x38fdffa7 _ZL12actionForKeyP7CALayerPN2CA11TransactionEP8NSString + 59
3     QuartzCore                            0x38fdfe93 _ZN2CA5Layer12begin_changeEPNS_11TransactionEjRP11objc_object + 131
4     QuartzCore                            0x38fdab87 _ZN2CA5Layer6setterEj12_CAValueTypePKv + 183
5     QuartzCore                            0x39007057 -[CALayer setBackgroundColor:] + 35
6     UIKit                                 0x3731ef51 -[UIView(Internal) _setBackgroundCGColor:withSystemColorName:] + 1021
7     APP NAME                              0x000a301d 0x00086000 + 118813
8     libdispatch.dylib                     0x3962511f _dispatch_call_block_and_release + 11
9     libdispatch.dylib                     0x39628ecf _dispatch_queue_drain$VARIANT$mp + 143
10   libdispatch.dylib                      0x39628dc1 _dispatch_queue_invoke$VARIANT$mp + 41
11   libdispatch.dylib                      0x3962991d _dispatch_root_queue_drain + 185
12   libdispatch.dylib                      0x39629ac1 _dispatch_worker_thread2 + 85
13   libsystem_c.dylib                      0x3824da11 _pthread_wqthread + 361

Answer 1

You need to symbolicate this crash report. Number 7 is the line you will be interested in, but there is no symbol information so the crash report cannot be translated into something useful for you. In order to symbolicate you need the exact code that was used in your app store release. If you have that, then you can reference this answer:

https://stackoverflow.com/a/13280585/1155387

As for the other things:

1) Don't be so quick to assume an internal API bug. Your function obviously changes the background color of a view, which calls various methods internally. It probably got passed an invalid value somehow. Don't be so naive as to think the code you write is the only code ever executed.

2) The + signs indicate the offset of that code inside of the binary object. Not useful for you.

3) You can easily have a memory error with ARC, because ARC only deals with the scope of Objective-C. Any CoreFoundation objects, etc, will not be managed. That's not necessarily what happens here but ARC doesn't mean you have to stop thinking about memory all together.

4) See above

5) See above