iOS Best easy way to debug EXC_BAD_ACCESS code 1

[subsonix]

Can you replicate the error? If so you have a bigger chance of identifying the code that is responsible. That backtrace you posted earlier seems to indicate you are using a NULL pointer somewhere, the address is 0.

 

[chadbag]

No need to step through all the code. Xcode allows you to set breakpoints that can generate NSLogs.

A Case Against Logging

In my experience, the app runs much slower when having the debugger evaluate all the breakpoints you want to log and then spitting out the log statement and then continuing. Maybe I was doing it wrong, but I went back to using NSLog or other logging statements when I want to do ad-hoc profiling or other similar printf-style debugging.
[doublepost=1454544723][/doublepost]

Nonsense. Debugging is a skill, like any other, and it takes practice to get good at it. However, there is no need to step through every line of code if using breakpoints.

I would argue that breakpoints and debug commands are a much faster, finer-grained way of debugging than log statements. You can add breakpoints to a running program, examine and even change the values of variables, run debug commands to display data structures or even execute code, etc.

With log statements you have to recompile and re-run each time you want to debug another small block of code. Sometimes getting a test set up or a bug to repeat takes a long time, and if you limit yourself to log statements, you might have to repeat that setup process over and over and over, getting a few lines further each time.

Of course neither is mutually exclusive. You can use both in the same debugging session, and you also add log commands to breakpoints so when the program hits a breakpoint it displays information just like you do with a log statement.

I speak from experience, mind. I've been using symbolic debuggers since VAX/VMS back in the mid 1980s. (And Xcode's symbolic debugger ranks among the best I've used.)

Using breakpoints instead of NSLog for ad-hoc profiling, in my experience, does not make sense due to the execution speed hit you take for the debugger to evaluate the breakpoint, do its action (like log), and then continue. The run time performance of simple embedded NSLogs is much greater. Note I am specifically talking about ad-hoc profiling where you can see where you've been etc. The execution path of your app.

Breakpoints certainly have their place and are very useful. As you said, both have their benefits. But trying to get runtime information (spit out info) and an execution path is much slower with breakpoints that continue execution.

And yes, the VAX/VMS debugger was quite nice in its time... Sigh... Lots of things were nice about VAX/VMS.
[doublepost=1454544835][/doublepost]

I hear what you're saying. But I choose C.

C. Add non-stopping breakpoints, which produce NSLog-type output in the console, in strategic places to indicate the best place to switch to a stopping-breakpoint so you can start stepping through code from there.

This is often impractical because the app execution really slows down as the debugger evaluates each breakpoint, does its action, and then continues. I read the case against logging a long while ago and tried it out and in many cases it was simply unworkable due to the performance impact on the app.

 

[Mascots]

Using breakpoints instead of NSLog for ad-hoc profiling, in my experience, does not make sense due to the execution speed hit you take for the debugger to evaluate the breakpoint, do its action (like log), and then continue. The run time performance of simple embedded NSLogs is much greater. Note I am specifically talking about ad-hoc profiling where you can see where you've been etc. The execution path of your app.

The only counter I'd have to that is that you can add and remove, enable and disable sets of breakpoints in an application on the fly without recompiling. IMO it's the greatest benefit. I think it's important to log generally to keep tabs on flow (my choice is Swell), but when investigating a problem spot or general tight points, breakpoints reign supreme. (Totes bumping this again because I like this thread)

 

[AxoNeuron]

Bad access errors can be tricky. This is usually why, when writing code, I test early and very frequently. This way, when a bug pops up, I generally know exactly what code it came from.

Sometimes it's not that simple though, and in those cases old fashioned logging can usually help you narrow down your search.

Also, in my code, at the top of every function I often write if statements (or guard statements in swift, even better) that help me to ensure that all my function parameters are always correct and don't contain weird/nil values when they shouldn't. It fires off a useful log statement then exits the function.

Break statements can also be extremely useful since as a previous poster said they let you see exactly what variables in your scope hold as their values. This is often insanely useful.

I wasn't always so careful or thoughtful when writing code and it caused me a considerable number of headaches. Getting to think like a computer takes a lot of time and effort but in the end it's totally worth it and becomes enjoyable. Eventually you will probably be able to write very sophisticated caching routines and other complicated types of code and it will work flawlessly on the very first run. That's rare but it's been happening for me more and more often lately, it just takes a lot of time and patience to get there.

 

[1458279]

IDK if anyone else does this, but I've done it a few times and it works.

As you make changes to your project, do a run and see if the area(s) you're working on still work. This allows you to isolate specific changes. I just had an issue with some silly mistyped id and it was caught by running a lot of quick runs in the sim.

There a tutorial about automating testing where it automatically goes thru your app, this should help with that.

If it's a game, that might be a different issue, I don't know how to debug games.