I am porting an app to macOS that takes over keyboard focus. It is seg faulting and I have no problems attaching lldb and running the program until it hits a breakpoint before entering the function that crashes.
lldb is now waiting for me to step through the program but even if I switch to Terminal.app, I can't use my keyboard because the program being debugged has taken over keyboard focus.
How do I interact with lldb in this circumstance?
I tried setting a new breakpoint on the first line of main.cpp and confirm I have keyboard focus in lldb.
I tried to set up debugserver so I attach to the process remotely on another computer:
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver 192.168.0.100:1234 --attach 1816
I have a dilemma in that I can't run the program directly because it crashes before I can attach to it. It is already running in lldb (1817) with the breakpoint before the crash:
debugserver-@(#)PROGRAM:LLDB PROJECT:lldb-1500.0.404.7
for arm64.
Attaching to process 1816...
error: failed to attach process 1816: (os/kern) invalid task - process 1816 is already being debugged by pid 1817
Exiting.
I'm not attached (ahem, no pun intended) to debugging remotely.
My preference is to debug locally and have a means to switch keyboard focus back and forth between the app being debugged and lldb.
I am open to ideas of the most effective way to debug an app that crashes during its initialization process.
The solution is to ssh into the computer hosting the process (eg. with an app like Termius) and run lldb on the app you are debugging in the remote terminal. Be sure to ssh in as the same user.
The app in macOS will not be able to takeover keyboard focus of the external device (in my case, an iPadPro) and you will be able to interact and use the debugger (lldb)
Be noted this procedure is not the same as remotely attaching to the process.
The procedure described above is akin to opening up a Terminal.app window on a different machine.
It solves the problem through the use of a completely separate keyboard whose focus cannot be captured by the remote machine.