When I get a crash report, the offending part of my code will sometimes look like this, instead of showing me the actual line number, even though the crash report is symboli
Your steps (image lookup + p/x addr + offset) will give you the raw address, as you found. But the original crash report probably included an address before the method + offset --- it is just as easy to slide your binary to the correct address using target modules load. At the end of the crash report there should be a list of the binary images present in the program, including load address and UUID.
But more importantly, while the address is nice what you're really after is the source location. In that case, once you've determined the correct address for the method (or slid it to the matching address via target modules load), you can use source list
(lldb) so l -a `addr + offset`
I'm using the backtick notation here which does an in-line expression evaluation. There's a handy shortcut for most commands that take an address: if you omit spaces, you can write the expression without backticks:
(lldb) so l -a addr+offset
You can also use image lookup with an address. If you have debug information, this will tell you what the current location of variables are at this point. Why is this useful? Because most crash reports include the register context at crash and so any variables that are currently in a register are provided to you (-v is necessary to get all of the register location information).
(lldb) im loo -v -a addr+offset
Finally -- this isn't going to work because you're dealing with an Objective-C method name -- but with a simple C function name you can do the offset arithmetic in-line as long as you cast the function name to a pointer type (it's not legal C to add an offset to a function pointer). e.g.
(lldb) so l -a (char*)main+10