The crash log of SIGABRT from the device is pointing on the lines:
NSArray *results = [self.managedObjectContext executeFetchRequest:request &error];
if ([results count] > 0 ) { // SIGABRT on this line.
and (for the same device):
if (myfunc(myobj)) { // SIGABRT on this line.
where myobj is a pointer that must be nil from the app configuration, and it is initialized in the line just before the line of the crash. myfunc is a function looking like:
BOOL myfunc(id object) {
return object != nil;
}
so i would consider the second crash as
myobj = something
if (myobj != nil) { // SIGABRT on this line.
My knowledge is not enough to understand the possibility of such crashes (probably they're even random) on certain devices (on the most devices everything works fine and stable).
Anyone had such issues or have an experience debugging it ?
There's no way how a pointer comparison can crash. Also, if myfunc is not a function pointer, if (myfunc(myobj)) cannot crash.
ReplyDeleteThe Objective-C code has not problems either.
Are you sure you're interpreting the debugger's output correctly? Are the debugging symbols correct? Try turn off optimization.
Maybe you are looking at the wrong stack: Check all thread's stacks.
SIGABRT is a signal sent to tell the process that something's wrong. Maybe it's just iOS killing your app because memory is running out. Or the process hits abort() due to a failed assertion.