0

My program crashes after indicating the following. I know something bad occured with the NSArrays. How should I trace the array variable which causes the exception?

enter image description here

alexwlchan
  • 5,699
  • 7
  • 38
  • 49
VARUN ISAC
  • 443
  • 3
  • 13
  • You can use NSLogs to see if the variable is null before called or you can use the console's function 'po' to print the objects description by referencing it's memory address. – max_ Apr 18 '14 at 20:45
  • Can't you get a good idea from the call stack? Looks like your deleting it in PurpleEventCallback but then accessing it after its deleted. But with XCode its possible to add breakpoints on a variable. – Gruntcakes Apr 18 '14 at 20:46
  • There is call stack left on the screen. Try click on it. – Cy-4AH Apr 18 '14 at 20:47
  • Are you declaring a property of type `NSArray`? What does your declaration look like? – Zev Eisenberg Apr 18 '14 at 22:13

2 Answers2

2

Tracing the array isn't going to help you here that much (but see below). You've overreleased something, probably the NSArray itself, and you're not finding out about it until the autorelease pool drains. These can be some of the hardest bugs to track down; hopefully it reproduces consistently.

The typical solutions are:

  • Make sure you're using ARC. This is precisely the kind of bug that ARC does an excellent job of avoiding. (And usually this kind of crash suggests you're not using it; but it is possible to get them under ARC in some cases.)
  • Work out which NSArray is having trouble. Audit its usage and make sure that (if you're not using ARC), you are following the memory management rules at each point. Regarding "work out which NSArray," this can be tricky in itself, but some common sense often is the best tool here. You probably have some sense of what object it is. A little trial and error can go a long way.
  • Avoid direct ivar access; always use accessors except in init and dealloc. This is the best way (besides ARC) to avoid these kinds of memory errors.

Instruments can add traces on retains and releases (use the Zombies instrument). And there is NSZombies, which can help as well. But I have found in the vast majority of cases, the best first step is to search for all the times you use the object, and then check your retains and releases by hand. (I'm not saying any of these approaches is easy; just that a quick by-hand audit is often more effective than the tools.)

And of course make sure to use ARC.

Community
  • 1
  • 1
Rob Napier
  • 286,113
  • 34
  • 456
  • 610
0

The BEST way to do this, which will help you on MANY occasions, is to set up XCode to automatically break when exceptions are thrown where they are thrown. You can do this as follows:

STEP 1: Go to the breakpoints navigator.

enter image description here

STEP 2: Go to the bottom left and hit '+' and add exception breakpoint.

enter image description here

STEP 3: Find the breakpoint you just added above, right-click, and edit.

enter image description here

STEP 4: Change it to break on all Objective-C exceptions, and the vast majority of crashes will break where the crash occurred.

enter image description here

When the exception occurs, you can act as if you're normally debugging - print values to the console, or hover over them to see what their values are.

Mike
  • 9,765
  • 5
  • 34
  • 59
  • 1
    The crash is a segmentation fault. Breaking on exception won't help. – Macmade Apr 18 '14 at 21:45
  • Ahh - well either way enabling this won't hurt :) – Mike Apr 18 '14 at 21:52
  • @Mike Thank you for the effort,NSZombies seems to provide some more crash reports effectively...http://stackoverflow.com/questions/5386160/how-to-enable-nszombie-in-xcode – VARUN ISAC Apr 19 '14 at 05:42