Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iOS EXACT line of code that crashed my app?
- Thread starter Buschmaster
- Start date
- Sort by reaction score
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...
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]
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]
That doesn't need to be included in the app as apple has taken the liberty to thread it all through v2.0
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.
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.
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.
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).
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).