I am dealing with a hard-to-reproduce memory crash, and troubleshooting using the guidance provided in the wwdc18 session 414 with additional clues from this so article
I have no issues symbolicating the stack trace (see at bottom), but when I try to disassemble the address from the last frame, I get this error from the lldb console:
(lldb) disassemble -a 0x00000001052faed4
error: error reading data from section __text
error: Failed to disassemble memory in function at 0x1052faed4.
Memory crashes are difficult, and in this case I really need to additional clues from the assembly code to sort it out.
Sadly the WWDC video flies through the setup/configuration, suggesting it should just work...but it doesn't. I suspect maybe some crucial configuration are missing from the video? Does anyone know how to get to the assembly code?
For reference, this is the top of the symbolicated stack trace (showing the crashing thread)
Thread[0] EXC_BAD_ACCESS (SIGSEGV) (KERN_INVALID_ADDRESS at 0x8000000000000010 -> 0x0000000000000010 (possible pointer authentication failure))
[ 0] 0x00000001052faed4 myApp`Flux.FASFluxDispatcher.invokeCallback(token: Swift.String) -> () + 60
[ 1] 0x00000001052faecf myApp `Flux.FASFluxDispatcher.invokeCallback(token: Swift.String) -> () + 55
[ 2] 0x00000001052fb2eb myApp `closure #1 () -> () in Flux.FASFluxDispatcher.doDispatch(action: Any) -> () + 195
[ 3] 0x00000001052feeb7 myApp `partial apply forwarder for reabstraction thunk helper from @callee_guaranteed () -> (@error @owned Swift.Error) to @escaping @callee_guaranteed () -> (@out (), @error @owned Swift.Error) + 19
[ 4] 0x00000001bff1ef30 autoreleasepool<A>(invoking:) + 64 (ObjectiveC.swift:172)
[ 5] 0x00000001052fb5af myApp `Flux.FASFluxDispatcher.dispatchAction(action: Any) -> () + 339
[ 6] 0x00000001052ff77f myApp `partial apply forwarder for closure #1 () -> () in Flux.FASActionCreator.dispatchAsync(action: Any, completion: Swift.Optional<() -> ()>) -> () + 111
[ 7] 0x00000001052fc0bf myApp `reabstraction thunk helper from @escaping @callee_guaranteed () -> () to @escaping @callee_unowned @convention(block) () -> () + 19
[ 8] 0x000000019967024c _dispatch_call_block_and_release + 32 (init.c:1454)
[ 9] 0x0000000199671db0 _dispatch_client_callout + 20 (object.m:559)
[ 10] 0x000000019967f7ac _dispatch_main_queue_callback_4CF + 836 (inline_internal.h:2548)
[ 11] 0x00000001999f911c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 (CFRunLoop.c:1790)
[ 12] 0x00000001999f3120 __CFRunLoopRun + 2508 (CFRunLoop.c:3118)
[ 13] 0x00000001999f221c CFRunLoopRunSpecific + 600 (CFRunLoop.c:3242)
[ 14] 0x00000001b15bc784 GSEventRunModal + 164 (GSEvent.c:2259)
[ 15] 0x000000019c432ee8 -[UIApplication _run] + 1072 (UIApplication.m:3253)
[ 16] 0x000000019c43875c UIApplicationMain + 168 (UIApplication.m:4707)
[ 17] 0x0000000104edcf67 myApp `main + 67 at AppDelegate.swift:29:9
[ 18] 0x00000001996b26b0 start + 4
Thread[1]
[ 0] 0x00000001c79cd1ac __psynch_cvwait + 8
[ 1] etc...
The DWARF file in the dSYM only has symbol information & debug information in it, it does not contain a complete copy of the binary's TEXT & DATA segments. If there is a copy of the binary next to the dSYM on the file system lldb will load that when it loads the dSYM. Or you can use the target modules add command to tell lldb to load the binary into the current session.