3

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...
Hugo
  • 974
  • 9
  • 21
  • As an alternative consider a static analysis of the Flux library disassembly using Hopper. You will need to figure out ASLR , but last 3 hex digits will stay constant – Kamil.S May 21 '21 at 08:29
  • Thanks @Kamil.S, I gave it a try, loaded the executable from .dSYM/Resources/DWARF into the tool, but every single instruction looks like `db 0x00 ; '.'` (exactly like this https://reverseengineering.stackexchange.com/questions/27409/how-to-add-instruction-in-a-new-segment-in-hopper-disassembler-on-arm64).Have you had success making it work? – Hugo May 21 '21 at 16:09
  • Sorry, I should have made the instructions more clear. You need to use Hopper on Flux framework binary (the one @Jim Ingham is referencing in his answer) not the DWARF file itself. – Kamil.S May 23 '21 at 07:01

1 Answers1

0

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.

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63
  • Thanks for the additional clues. I am a sad noob when it comes to using LLDB...could you add some details? How can I get my hands on the binary - is that a file that is automatically generated and is typically part of the Xcode archive, or is it a file that needs to be generated in an ad-hoc fashion (like an .ipa file?) – Hugo May 22 '21 at 21:09
  • @Hugo In your decompressed ipa that would be `Frameworks/Flux.framework/Flux` binary file. I'm guessing it would be `Flux`. Still I expect the name to be pretty close to that. – Kamil.S May 23 '21 at 06:57
  • 1
    Flux is a Swift Package, I don't think it gets its own binary. This said all the comments were very useful...it took me a while to understand what it all meant, but finally moved the MyApp.app package from the archive to make it available at the path referenced by the crashlog (`/private/var/containers/Bundle/Application/D048A52F-E4BE-4EE0-A1DA-9B0A4A9AE51B/MyApp.app`). Both symbolication & disassembly started working after that – Hugo May 25 '21 at 05:03