Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

iOS Best easy way to debug EXC_BAD_ACCESS code 1

M

moonman239

Cancelled
Original poster
Mar 27, 2009
1,541
32
Maybe it's just me, but NSZombies did not seem to do the trick this time. I also have malloc logging enabled, but I don't know very much about it.

I guess I'm just too lazy to figure out all this stuff myself.
 
moonman239 said:
Maybe it's just me, but NSZombies did not seem to do the trick this time. I also have malloc logging enabled, but I don't know very much about it.

I guess I'm just too lazy to figure out all this stuff myself.
Click to expand...

There is no magic bullet. You need to understand the basics of object ownership, pointers, and various other topics, or your programs will not run reliably.

Figuring out why your program is crashing takes some detective work. Sometimes a LOT of detective work.

If you're "too lazy to figure out all this stuff" then you need a new hobby. It's like trying to build a gas engine from a block of steel without learning engineering. It's too complex and finicky to work without understanding the underlying principles.

Get a good book on iOS development, with exercises, and read it cover to cover, and do the exercises. It will save you a lot of time and frustration in the end.
 
Duncan make an excellent point. Most can get to the point where they can build a program and make it run, but there can be some real work in making changes to a program and hunting down bugs.

I've seen 'programmers' that spend huge time on simple errors.

One method that I like to use is to fully test a version that works, then each thing you change/add fully test again. That way you'll know what changes caused the problem.

You can also look back at what could cause the problem, and find known-good code (sample code, or code from a known good program) This way you can limit it down to a small section of code that's causing the problem.

Debugging is a part of programming, many don't like it, but most every programmer will have to do it.
 
As Duncan said, you should look for something else you like to do.

If you are too lazy then programming is just not your thing and no one will do your work for you. If you need help, this is not the right attitude.
 
Sonnestah said:
As Duncan said, you should look for something else you like to do.

If you are too lazy then programming is just not your thing and no one will do your work for you. If you need help, this is not the right attitude.
Click to expand...

I understand that these errors are typically generated when an app calls an object that has been released because no existing object wants to own the object.

I found out about Crashlytics a few days ago. Do you think that will help?

EDIT: I should add that my app uses ARC, which I understand automatically releases an object when it sees that it is no longer needed.
 
moonman239 said:
I understand that these errors are typically generated when an app calls an object that has been released because no existing object wants to own the object.

I found out about Crashlytics a few days ago. Do you think that will help?

EDIT: I should add that my app uses ARC, which I understand automatically releases an object when it sees that it is no longer needed.
Click to expand...


I've never heard of Crashlytics.

There is no magic bullet that is going to let you debug and fix your code without understanding what you are doing.

This is a technical discipline, and requires study and sustained effort to master

If you are lazy and don't want to invest the effort to understand the basics of Cocoa programming, pick a different hobby.
 
moonman239 said:
Maybe it's just me, but NSZombies did not seem to do the trick this time. I also have malloc logging enabled, but I don't know very much about it.

I guess I'm just too lazy to figure out all this stuff myself.
Click to expand...

It's not a 'trick' You need to look at this as science, computer science. You not following one or more of the rules concerning memory, objects or something. You need to dig in and figure out what you've done wrong.

Using some aftermarket patch is NOT the answer. In order to properly and effectively debug a program, you need a in depth understanding of how things work "under the hood"

You're making it sound like you are a "cut and paste" programmer or someone that's skimmed through the documents without taking the time to fully understand the concepts or proper usage. Programming is not something you can shortcut.
 
So far, I ran scan-build & used NSZombies. Neither helped me identify the cause of the problem.
 
May I ask what your goal is for your app? Is it just for fun or is it headed to the App Store? Are you going to be an independent iOS developer or are you looking to be employed by somebody else? Things to think about.

Have you tried using NSLog statements or stepping through the code?

What I do is place NSLog statements at the beginning of every method. The statement logs the class of the object and the name of the method. That way, if I get a crash I look and see what the last method was that was called. Then I can set a break point in that method and step through it.

I don't log the name of every method all the time; I comment and uncomment as needed.
 
TheWatchfulOne said:
Have you tried using NSLog statements or stepping through the code?

What I do is place NSLog statements at the beginning of every method. The statement logs the class of the object and the name of the method. That way, if I get a crash I look and see what the last method was that was called. Then I can set a break point in that method and step through it.

I don't log the name of every method all the time; I comment and uncomment as needed.
Click to expand...

Actually, one developer says it's better to use breakpoints rather than inserting NSLogs into the code. You don't have to take time to remove them before you submit the app to the App Store, and you don't run the risk of introducing more bugs into the code.

Anyways, I came to this thread to post a backtrace that LLDB printed after the app crashed:

Code: 
* thread #7: tid = 0x33ce3, 0x00000000, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00000000
    frame #1: 0x0001bf4a Words app`___lldb_unnamed_function365$$Words app + 54
    frame #2: 0x0001f640 Words app`___lldb_unnamed_function440$$Words app + 24
    frame #3: 0x2eb75182 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
    frame #4: 0x2eb74652 CoreFoundation`__CFRunLoopDoSources0 + 206
    frame #5: 0x2eb72e46 CoreFoundation`__CFRunLoopRun + 622
    frame #6: 0x2eaddc26 CoreFoundation`CFRunLoopRunSpecific + 522
    frame #7: 0x2eb2173a CoreFoundation`CFRunLoopRun + 98
    frame #8: 0x0001f602 Words app`___lldb_unnamed_function439$$Words app + 194
    frame #9: 0x2f58dc86 Foundation`__NSThread__main__ + 1062
    frame #10: 0x398a2c1c libsystem_pthread.dylib`_pthread_body + 140
    frame #11: 0x398a2b8e libsystem_pthread.dylib`_pthread_start + 102
 
moonman239 said:
Actually, one developer says it's better to use breakpoints rather than inserting NSLogs into the code. You don't have to take time to remove them before you submit the app to the App Store, and you don't run the risk of introducing more bugs into the code.
Click to expand...

Well I guess you have a choice then.

You can spend time inserting (and commenting/uncommenting) NSLog statements in strategic places, or you can spend time stepping through ALL of your code until you finally get that EXEC_BAD_ACCESS error.

I'd rather log information to the console that will give an idea of where to place the break point such that I don't have to step too far to reach the EXEC_BAD_ACCESS.

You can search you project and replace "NSLog" with "// NSLog" when they are no longer needed. :)
 
TheWatchfulOne said:
Well I guess you have a choice then.

You can spend time inserting (and commenting/uncommenting) NSLog statements in strategic places, or you can spend time stepping through ALL of your code until you finally get that EXEC_BAD_ACCESS error.

I'd rather log information to the console that will give an idea of where to place the break point such that I don't have to step too far to reach the EXEC_BAD_ACCESS.

You can search you project and replace "NSLog" with "// NSLog" when they are no longer needed. :)
Click to expand...

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.)
 
dejo said:
No need to step through all the code. Xcode allows you to set breakpoints that can generate NSLogs.

A Case Against Logging
Click to expand...

Agreed, which is why I don't step through every line of code as indicated by the paragraph in my post that comes right after the one you quoted.


Duncan C said:
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.
Click to expand...

Obvously I wasn't clear. moonman239 indicated a reluctance to use NSLog. So I said he had a "choice":
A. Step through all the code (more time-consuming)
B. Add NSLog statements in strategic places to indicate the best place to put a break point so you don't have to step though so much code. (less time-consuming)

I choose B

My apologies for not communicating clearly. :)
 
TheWatchfulOne said:
Obvously I wasn't clear. moonman239 indicated a reluctance to use NSLog. So I said he had a "choice":
A. Step through all the code (more time-consuming)
B. Add NSLog statements in strategic places to indicate the best place to put a break point so you don't have to step though so much code. (less time-consuming)

I choose B

My apologies for not communicating clearly. :)
Click to expand...

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.

:)
 
dejo said:
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.

:)
Click to expand...

I started to add "C" to the list. It was going to say "I don't know C" but I decided that didn't sound like a very good thing for me to say in this thread. :eek:

I also set a break point in my own code to play around with (I use Windows on the job, but during lunch, the Mac comes out of hiding) and when I right clicked on that break point I discovered there is so much more to break points than what I had thought (I figured there was - I just hadn't explored it up to this point.)

And I was indeed able to log the same information to the console using a break point that I was way back when I used to to used to make extensive use of NSLog. And as Duncan C mentioned, I didn't have to stop my debug session in order to make it do something different. Sweet!!!:D
 
My backtrace says one of my run loops is calling out to a "source0 perform function."

What's a source0 perform function?
 
I think I have narrowed the problem down to a line of code where an NSTimer is created. The timer is set to tell an existing object to fire one of that object's methods. I think the object exists, because I tried rewriting the code so that the object was explicitly declared as a property to which the class holds a strong reference and I think I still got an EXC_BAD_ACCESS error.

EDIT: What's weird is that this line of code seems to work in the other classes in which it is used.
 
If you think the problem is in the timer, I'd look at something that might have changed while the timer is active.

Example: you call a timer to check the value of something that's been removed by something else. Like calling something that's no longer there.

A simple IF statement to check if something is there could answer the question.
 
moonman239 said:
I think I have narrowed the problem down to a line of code where an NSTimer is created. The timer is set to tell an existing object to fire one of that object's methods. I think the object exists, because I tried rewriting the code so that the object was explicitly declared as a property to which the class holds a strong reference and I think I still got an EXC_BAD_ACCESS error.

EDIT: What's weird is that this line of code seems to work in the other classes in which it is used.
Click to expand...

This may sound completely out of left field, but are you by any chance using NSInvocation to call the method on the other object and does the called method return a value that you are trying to access?
 
TheWatchfulOne said:
This may sound completely out of left field, but are you by any chance using NSInvocation to call the method on the other object and does the called method return a value that you are trying to access?
Click to expand...

No to both questions. I am using performSelector.

Anyways, the problem does not seem to lie in the timer itself. It looks like the object being targeted has been deallocated from memory, but like I said before, I didn't get any complaints from any NSZombie.

EDIT: What I mean is that I got an EXC_BAD_ACCESS error just by calling one of the object's methods.

EDIT 2: When I ran the app on the simulator I got a code 2 EXC_BAD_ACCESS error. The error I got when I ran the app on my iPad was a code 1 EXC_BAD_ACCESS error. Therefore, I could use malloc debugging but I'm not sure if it will help.
 
Last edited:
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back