EXACT line of code that crashed my app?

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

  1. macrumors 65816

    Buschmaster

    Joined:
    Feb 12, 2006
    Location:
    Minnesota
    #1
    Is there a way using instruments that I can see which instruction crashed my app?

    Thanks.
     
  2. Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #2
    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. thread starter macrumors 65816

    Buschmaster

    Joined:
    Feb 12, 2006
    Location:
    Minnesota
    #3
    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

    JNB

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

    :p
     
  5. macrumors G3

    TuffLuffJimmy

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

    xsmasher

    Joined:
    Jul 18, 2008
    #6
    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. macrumors 603

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #7
    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. macrumors member

    Joined:
    Jul 9, 2008
    #8
    Console

    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