Best easy way to debug EXC_BAD_ACCESS code 1

Discussion in 'iOS Programming' started by moonman239, Oct 21, 2013.

  1. moonman239 macrumors 68000

    Joined:
    Mar 27, 2009
    #1
    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.
     
  2. Duncan C macrumors 6502a

    Duncan C

    Joined:
    Jan 21, 2008
    Location:
    Northern Virginia
    #2
    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.
     
  3. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #3
    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.
     
  4. Sonnestah macrumors regular

    Joined:
    Mar 2, 2013
    #4
    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.
     
  5. moonman239 thread starter macrumors 68000

    Joined:
    Mar 27, 2009
    #5
    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.
     
  6. Duncan C macrumors 6502a

    Duncan C

    Joined:
    Jan 21, 2008
    Location:
    Northern Virginia
    #6

    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.
     
  7. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #7
    No, I don't. Can you explain why you think it will?
     
  8. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #8
    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.
     
  9. moonman239 thread starter macrumors 68000

    Joined:
    Mar 27, 2009
    #9
    So far, I ran scan-build & used NSZombies. Neither helped me identify the cause of the problem.
     
  10. TheWatchfulOne macrumors 6502

    Joined:
    Jun 19, 2009
    #10
    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.
     
  11. moonman239 thread starter macrumors 68000

    Joined:
    Mar 27, 2009
    #11
    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
    
     
  12. Duncan C macrumors 6502a

    Duncan C

    Joined:
    Jan 21, 2008
    Location:
    Northern Virginia
    #12

    See my first post in this thread.
     
  13. TheWatchfulOne macrumors 6502

    Joined:
    Jun 19, 2009
    #13
    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. :)
     
  14. dejo Moderator

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #14
    No need to step through all the code. Xcode allows you to set breakpoints that can generate NSLogs.

    A Case Against Logging
     
  15. Duncan C macrumors 6502a

    Duncan C

    Joined:
    Jan 21, 2008
    Location:
    Northern Virginia
    #15
    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.)
     
  16. TheWatchfulOne macrumors 6502

    Joined:
    Jun 19, 2009
    #16
    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.


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

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #17
    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.

    :)
     
  18. TheWatchfulOne macrumors 6502

    Joined:
    Jun 19, 2009
    #18
    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
     
  19. moonman239 thread starter macrumors 68000

    Joined:
    Mar 27, 2009
    #19
    My backtrace says one of my run loops is calling out to a "source0 perform function."

    What's a source0 perform function?
     
  20. moonman239 thread starter macrumors 68000

    Joined:
    Mar 27, 2009
    #20
    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.
     
  21. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #21
    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.
     
  22. TheWatchfulOne macrumors 6502

    Joined:
    Jun 19, 2009
    #22
    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?
     
  23. moonman239, Nov 5, 2013
    Last edited: Nov 5, 2013

    moonman239 thread starter macrumors 68000

    Joined:
    Mar 27, 2009
    #23
    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.
     
  24. Sonnestah macrumors regular

    Joined:
    Mar 2, 2013
    #24
    If you post your code we will be able to help you
     
  25. thekev macrumors 604

    thekev

    Joined:
    Aug 5, 2010
    #25
    Regarding your first post, do you have a favorite for someone who already knows C/C++ yet not so much Objective C?
     

Share This Page