EXACT line of code that crashed my app?

Discussion in 'iOS Programming' started by Buschmaster, Jul 27, 2008.

  1. Buschmaster macrumors 65816


    Feb 12, 2006
    Is there a way using instruments that I can see which instruction crashed my app?

  2. kainjow Moderator emeritus


    Jun 15, 2000
    Use the debugger? If you're running in Debug mode and it crashes, open up the debugger before stopping the process and it should show you the stack trace.
  3. Buschmaster thread starter macrumors 65816


    Feb 12, 2006
    I'm pretty confused by this.

    I said build and debug and then opened the debugger and when it crashed where it always does right now it showed a bunch of stuff but I didn't really figure out how to get the actual line of code out of it...
  4. JNB macrumors 604


    Oct 7, 2004
    In a Hell predominately of my own making
    Was it this one?
    [B][COLOR="Blue"]tell[/COLOR][/B] [COLOR="blue"]application[/COLOR] "iPhone App" [B][COLOR="blue"]to[/COLOR][/B] [COLOR="blue"]trainwreck[/COLOR]

  5. TuffLuffJimmy macrumors G3


    Apr 6, 2007
    Portland, OR
    That doesn't need to be included in the app as apple has taken the liberty to thread it all through v2.0
  6. xsmasher macrumors regular


    Jul 18, 2008
    You have 200 lines of code, and any one (or more) could be the culprit. You have to narrow it down, figure out what's working and what's not.

    I make copious use of NSLog, so I can look at the console and get a general idea of what methods are being called. For example I may add, in the "init" method of my view class: NSLog(@"view was init-ed");

    Then, when I look at the console (Run > Console on the menu) I'll see which methods were called before the crash, and how many times. If I see my app is crashing after the database is loaded, but before the screen is displayed, I now know better where to look.

    You can also set breakpoints; go to a line that you think is being executed, and click in the grey area to the right of the editor. A blue arrow (a breakpoint) will appear. Now when you build and run your app, it will stop at that point and you can step through your application one line at a time until you find the line that crashes it.

    One word of warning - if the crash is caused by a memory leak, it may "disappear" when stepping through by line, and reappear when you run at full speed. I had at least one EXC_BAD_ACCESS that only occurred when running normally, not when stepping through line by line. I had to add a lot of NSLogs to find that one.

    The debug log may also be telling you if, for example, you're calling a method that is not defined; you should slog through it and see what is says.
  7. firewood macrumors 604

    Jul 29, 2003
    Silicon Valley
    single step

    Use the stack trace in the debugger to find the function where it crashed. Put a breakpoint at the beginning of that function, restart the app, and single step one line at a time until something unexpected happens.
  8. caldwelljason macrumors member

    Jul 9, 2008

    It can also be helpful to look at the dbg console and see if there was an exception. Sometimes the exception information will give you a hint where to look.

    For example, if you see that the exception that crashed the program was that the message doSomething could not be sent to object myObject, look for a place where you send that message to that type of object.

    Another approach that sometimes works is to set a breakpoint in the last "known good" spot (I know I can load this view) and then step through the code, looking for things to go awry (variables to be in unexpected states, methods not called that you expected to be called, etc). Sometime you can step until you blow up and then you know where it was. This is similar to the NSLog approach, but more interactive (and more time consuming).

Share This Page