30

I received an error

EXC_BAD_ACCESS code=2 at0xb0987654

I am wondering how to print out the value at 0xb0987654?

Adam Lee
  • 24,710
  • 51
  • 156
  • 236
  • 1
    I suppose you don't wanna print out the value at that address since that very address is your problem in the first place. What *got you there* is the question to ask. – Jay Nov 01 '14 at 06:41

3 Answers3

35

To debug an EXC_BAD_ACCESS, you can generally find out the where the dangling pointer is by enabling zombie objects.

Xcode

Product > Scheme > Edit Scheme

Then, config like below enable zombie objects

AppCode

Choose edit target, and add the following environment variable:

NSZombieEnabled=YES

Another cause for EXC_BAD_ACCESS can be infinite recursion, which can be found by adding some logging.

Update for C++:

To debug dangling pointers in C++ with the Clang compiler try using Address Sanitizer (ASAN) from Google.

Mamad Farrahi
  • 394
  • 1
  • 5
  • 20
Jasper Blues
  • 28,258
  • 22
  • 102
  • 185
  • @AdamLee How about this then? http://stackoverflow.com/questions/3199067/c-catching-dangling-reference – Jasper Blues Nov 02 '13 at 12:04
  • @AdamLee, Oops looks like MudFlap is gcc only, updated for Clang/llvm – Jasper Blues Nov 03 '13 at 03:21
  • Ever got the **AddressSanitizer** working with Xcode?? On all Xcode versions I've tried yet the 'special' clang version included by Apple doesn't feature support for `-fsanitize`.. – Jay Sep 01 '14 at 16:34
  • @Jay Have not tried recently . . mostly ObjC lately. Found any workaround or other approach? – Jasper Blues Oct 27 '14 at 13:26
  • 1
    @JasperBlues in these day's I'm just using the Instruments templates for any kind of Obj-C memory errors.. and years of experience, extensive error checks plus heaps of logging for the bad, C++ ones..... – Jay Nov 01 '14 at 06:40
3

It looks like maybe you are trying to write onto a code page or something? EXC_BAD_ACCESS is described in /usr/include/mach/exception_types.h:

#define EXC_BAD_ACCESS          1       /* Could not access memory */
            /* Code contains kern_return_t describing error. */
            /* Subcode contains bad memory address. */

And from kern_return.h:

#define KERN_PROTECTION_FAILURE         2
            /* Specified memory is valid, but does not permit the
             * required forms of access.
             */

You can see WHERE that address is in your binary by doing:

(lldb) image lookup -va 0xb0987654

But what you really need to figure out is who is trying to write there. If the problem is simple this might tell you what's wrong, but as Jasper suggests, this is probably some use-after-free or other such problem, and the bad actor is long gone by the time you crash. guardmalloc can also sometimes catch this sort of error (you can enable this in Xcode in the Run scheme.)

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63
  • 10
    `image lookup -va 0x1586470c4` in lldb gives me no output at all, not even an error message. – Translunar Jun 09 '14 at 17:55
  • At present "image lookup -a" just prints what it can find at a given address, even in the case of "no symbols at this address" when that is nothing... LLDB should really print some error when it can't find any symbols associated with a given address. Please file a bug about this either with Apple's bug reporter or the lldb.llvm.org bugzilla. Thanks. – Jim Ingham Jun 10 '14 at 18:49
-1

Identify what you did that caused the crash. Did it crash while view of a particular view controller didLoad or in a delegate method or on a particular action. That will often help to find the object that is casuing the error.

  • Most of the time “NSZombies” can help to identify the dead object. You can enable NSZombies by editing your scheme Product -> Edit Scheme -> Diagnostics.
  • If you still don’t find the root cause then always go backwards from child view controller to parent view controller to see what object needs to be retained or what message needs to be passed properly.
  • Look into Static Analyzer and Instruments for advanced debugging.

I hope this will help you.

Regards, Gison

Gison George
  • 379
  • 1
  • 3
  • 15