How to Find the Address of a Stack Trace in Lldb for iOS

How can I trace the value of an address in memory?

The equivalent instructions in lldb for Jester's gdb steps are:

(lldb) image lookup -va <ADDRESS>

That will tell you everything lldb knows about that address.

Getting info about bad memory address in LLDB

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.

LLDB command to view human-readable values at specific memory addresses

Sure. If you want raw memory dumps, try the memory read command. If you have debug info for the type of the object, you can pass it to the -t option to memory read (this is more useful for arrays of objects.)

Or you can use the expression parser, something like:

(lldb) expr ((MyObjectType *) 0x18138b90)

If you are in frames with debug info, you can also use frame variable to view locals & arguments. So for instance:

(lldb) frame variable *object

should show you the contents of object.

LLDB stack trace only shows last 2 calls in XCode

Try printing [NSThread callStackSymbols] from the debugger, which sometimes works when the debugger doesn't. It doesn't really surprise me that

Additionally, my experience is that GDB is far more reliable.

What is ___lldb_unnamed_symbol?

In the main executable of an app, Objective-C code is stripped out so LLDB is unable to read these symbols. This is different than dynamically linked frameworks, where you can still resolve the symbols.

That being said, you're going after Objective-C, so you can use the Objective-C runtime against itself. There's a number of ways to find the location of that method when loaded into memory. But since I see you're using the regex option in that breakpoint, I'd suggest you take a look at this custom LLDB script that can search the main executable for stripped out classes

https://github.com/DerekSelander/LLDB/blob/master/lldb_commands/lookup.py

This command, called lookup, can be used like so:


(lldb) lookup -X \[ThirdPartyClass\s


Using the -l argument you can get the load address of these methods

(lldb) lookup -X -l \[ThirdPartyClass\s


And of course you can set a breakpoint on all these methods with the -B option

(lldb) lookup -X -B \[ThirdPartyClass\s


You can see this lookup command being used in this video https://youtu.be/gxfrJuxwblI?t=20m50s

---

Related Topics