2

Ok. So I had this extremely weird SIGABRT error on a complex Objective-C iOS program that I'm working on, and after one day of tracking I found the culprit.

Let's say we have the following code:

NSArray *a = [NSArray arrayWithObjects:@"a", @"b", @"c", nil];
NSLog(@"tada: %@", [a objectAtIndex:-1]);

Why the hell will this terminate the program with Program received signal: SIGABRT and the debugger not even pointing to my code (but rather in some assembly part) instead of a nicer 'index out of bounds' and 'hey, this line of code here be wrong' error?

I thought I messed up the project config, so I reproduced this on a brand new project: same result.

Is there a way to configure XCode to be more nice and indicate this kind of errors in a more human understandable way ?

Nicu Surdu
  • 8,172
  • 9
  • 68
  • 108

2 Answers2

2

As the documentation says:

If index is beyond the end of the array (that is, if index is greater than or equal to the value returned by count), an NSRangeException is raised

And the default action, when no exception handler is defined, is to... well... you can see what the default behaviour is.

You can use @try/@catch to trap the exception, but that's not really Objective-C-ish. You know how many elements are in the array; there's no real need for you to be accessing elements that don't exist.

Exceptions like this normally have a stack trace, so you can go back to the line of code causing the error. (It might be worth switching between LLDB and GDB if it's not working correctly. LLDB is faster and smaller but not completely reliable.(

Stephen Darlington
  • 51,577
  • 12
  • 107
  • 152
  • 1
    I'll have to try what you suggest: switching from LLDB to GDB, because the stack trace is useless now. As far as try catch idea is worth, if I knew the error was there, so that I can surround it with try catch, I would of fix it in the first place :). I need to know in the future more details about where the error is, not to browse tons of code ... I'll get back with you ass soon as I have the time to test this :) – Nicu Surdu Apr 13 '12 at 14:04
  • And in all fairness, -1 is lower than the value returned by count :P. But also, not a NSUInteger ... – Nicu Surdu Apr 13 '12 at 14:05
  • I'd love to hear your explanation of *why* @try/@catch isn't "Objective-C-ish." – Extra Savoir-Faire Apr 13 '12 at 14:14
  • 2
    I guess more correctly it's not Cocoa-ish. It's not that it's invalid code, it's just that in the iOS and Mac SDK's exceptions are very, very rarely used. Error handling tends to be managed using delegates, NSError's, return codes, etc. – Stephen Darlington Apr 13 '12 at 14:33
  • Totally agreed. For more on this, see "Exception Programming Topics." It explains the very limited use of exceptions in ObjC. Note that ARC intentionally leaks when you throw exceptions (the rationale is that after an exception, your program should terminate in the very near future). @catch is just there to give you a chance to do critical things prior to terminating the app (often it's just a chance to log). https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Exceptions/Exceptions.html – Rob Napier Apr 13 '12 at 15:52
  • @StephenDarlington I see now that GDB is my only option for iOS, so your suggestion of changing the debugger is not valid. Any other idea what can be done for debugger to be more explicit about what error occurs where ? I had another issue with a weird `SIGABRT`, I fixed it by pure chance, not because the GDB was pointing me in the right direction ... – Nicu Surdu Apr 17 '12 at 13:22
  • @NicolaeSurdu You might want to upgrade to Xcode 4.3.x, then. – Stephen Darlington Apr 17 '12 at 13:29
  • @StephenDarlington the question was asked in 2012 :) – Nicu Surdu Jul 31 '18 at 13:17
2

You should see something along the lines of "index of out range" if you look in the console log in Xcode. SIGABRT is the result of an assertion being fired. Sometimes you have to hit "Continue" after the crash in order to get the message to print.

The debugger tells you where the crash actually happened. It doesn't know what the original cause was. If the debugger leaves you looking at the assembler, just move up the stack until you reach your code.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610