Getting info about bad memory address in LLDB

Question

I am trying to debug an EXC_BAD_ACCESS in my iPhone app. It is crashing on a method call and on the line of the method is EXC_BAD_ACCESS (code=1, address = xxx).

Before, I would have just used gdb info malloc-history <xxx> to start debugging, but I am having trouble finding a parallel command in LLDB.

I saw this thread that said to use Instruments, but when I do I still get the crash but I can't figure out how to tell exactly where the app is crashing from in Instruments.

I just need to figure out where this piece of memory that is crashing was pointing to. What is the best way to do this either using LLDB or Instruments?

Solution 1

This problem is very easy to solve with an informative backtrace. Unfortunately with the latest version of iOS and Xcode, a good stack track is sometimes hard to come by. Fortunately you can set an 'Exception Breakpoint' in Xcode to allow you to examine this code prior to the EXC_BAD_ACCESS exception.

1. Open the breakpoint navigation in Xcode 4 (This looks like a rectangle with a point on the right side)
2. Press the '+' button at the bottom left and add an 'Exception Breakpoint'. Ensure you break 'On Throw' for 'All' exceptions.

Now you should get a full backtrace immediately prior to this exception occurring. This should allow you to at least zero in on where this exception is being thrown.

Solution 2

You can see the malloc stack if you debug using instruments.

I encountered the same problem as you and similarly wanted to know how to get the malloc history when using lldb. Sadly I didn't find a nifty command like malloc-history found in gdb. To be honest I just switched my debugger over, but I found that annoying since I felt I shouldn't have to do that.

To find the malloc history using instruments:

1. Profile your project
2. Select Zombies from the list of instruments
3. Make your app trigger the problem
4. At this point you should be presented with the address that was already deallocated and you can explore it. It should be a simple matter of viewing the malloc history at this point. I blacked out portions that had class / project names specific to the work I'm doing, but I think the essence and usefulness of how to go about getting this information is present.

A Last Word

The problem I ran into yielded a message like:

*** -[someClass retain]: message sent to deallocated instance 0x48081fb0 someProject(84051,0xacd902c0) malloc: recording malloc stacks to disk using standard recorder

I was really puzzled where this retain was coming from since the code it was breaking on didn't have one (not in the getter or setter of the line it was on). It turns out that I was not calling removeObserver:forKeyPath: when a certain object was dealloc'ed. Later in execution KVO occurred do to a setter on a line and that blew up the program since KVO was trying to notify an object that was already released.

Solution 3

you can use command like this in lldb:

image lookup --address 0xec509b

you can find more commands at:LLDB TO GDB COMMAND MAP

Solution 4

Maybe is too late but for further assistance, on LLDB:

(lldb) p *(MyClassToPrint*)memory_address

E.g.

(lldb) p *(HomeViewController*)0x0a2bf700

View more solutions

Comments

[calimarkus]

Have you tried to turn NSZombie on? That helps in many EXC_BAD_ACCESS cases!

[Eimantas]

So you're getting crash on device or simulator? NSZombie works only on simulator.

[Ross Kimes]

I did not realize that. That explains why I never saw any difference when working with NSZombie. Thanks!

[Ross Kimes]

Both of your answers were really helpful, but this is how I ended up figuring out where my problem was. Now I just have to fix it :). Thanks for all the help!

[Richard J. Ross III]

Thank you! I didn't have zombie issues, in fact I was just digging through the data encapsulated by a CGImageRef. This was the trick!

[Nikita P]

@tristan its not printing anything :(

[Nav]

is there a way to debug stray kvo notifications ?