Topic : Attaching debugger via lldb to remote process on tv device Current status I launch an app on a remote tv device that is paired to a macbook using the command xcrun devicectl device process launch --start-stopped -d XXXX-XXXXXX, com.metasample.SampleApp -j launch.json App is launched in stopped state and waiting for debugger to be attached to continue execution Using the XCode->Debug->Attach to Process, I am able to select the process and connect to the process and execute the app through the debugger. Expectation I would want to replace step 3 and use a command line instead to attach the debugger to the remote process instead of doing it via XCode.(the reason is to automate the execution without any manual intervention) I know the process id of the app on the remote tv device when i inspect the launch.json file that is created when the launch the app. eg pid 312 I also know the ip address of the device eg ip 192.168.178.29 However I do not know how to establish the debug session using lldb from command line. I launch lldb in the command line and execute these commands platform select remote-tvos target create /Users/works/apps/SampleApp-Payload/SampleApp.app/SampleApp gdb-remote 192.168.178.29: "what is the port?" - I do not know what port to connect to? Many Thanks for your suggestions and inputs on how to connect to the remote app via command line lldb.

I'm writing a C/C++ command line program which, at some point, calls IOHIDManagerOpen. I've added both my program executable and lldb as permitted for input monitoring (as far as I remember, my program was added after showing up a permission prompt, I've added lldb manually later, trying to resolve the problem). My problem is that when I run my program from within lldb in Terminal, the call to IOHIDManagerOpen returns kIOReturnNotPermitted. When I run my program directly in the terminal session (without lldb), this call returns kIOReturnSuccess. Such behaviour means it will be impractical to use lldb for any debugging of this program. What can be done to make lldb session behave the same way, the normal execution works? I'm on: 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:55:06 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6020 arm64 and: lldb-1500.0.200.58 Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5)

Hello, is there any way that I can automatically fold items in the console? I do log all API requests and responses, printed in a nice json to console. It works well, but having a lot of requests makes the console very big, and it kills readability, I have noticed that I can manually fold json printed in console with CMD+OPTION+Left shortcut. I am asking if that's possible to fold everything, or just display first lines of the console. So I can see more entries easier, and if I need I can unfold, or disable Line Wrap, to see details. I am attaching the photo of how code folds works there. It's all good, but I need to do it one by one, which is bad. If I could select everything and auto-fold, or It has the line wrap disabled. I

I am trying to debug a kernel panic in our kext. I can attach to the target Mac over ethernet if I: cause an NMI using add an IOPanic call to my kext and cause it to be executed use Dtrace to invoke a panic However if I reproduce the kernel panic which I am investigating, the Mac just restarts. How can I make the Mac wait for me to attach with lldb rather than restarting? My target configuration is: Mac is 2021 M1 Pro 14" MacBook Pro macOS 14.2 (23C64) Network: Apple Thunderbolt 3 <-> Thunderbolt 3 adapter + Apple Thunderbolt 2 to ethernet adapters Boot-args = "debug=0x44 wdt=-1 kdp_match_name=en8" (I have also tried debug=0x104C0C)

When po an NSObject variable in lldb in Xcode 15.1，an error occurs，this error description is "error: Internal error [IRForTarget]: Couldn't change a static reference to an Objective-C selector to a dynamic reference" Has anyone encountered this situation? How can i fix this?

Yesterday, my code ran just fine under the previous Xcode version. Today, some print() statements seem to come with extra lines. I know it sounds stupid, but my code did not change in the meantime. It doesn't appear to come from anything I control, almost like some Apple code emits an extra line feed somewhere. It's just a Swift Mac App I built to make my digital art; otherwise, nothing else is incorrect, just these odd lines. It's not as simple as just making a test case with a few print("***") statements, it seems to require other code to run in between calls to print. Most of my app is using CoreGraphics. It has no UI. It's like when you see spurious Apple debugging info in the console sometimes, but it's only a blank line this time. It's not a big issue, just annoying.

In an old document from Apple(Debugging An Authorization Plug-In With Xcode), a method was taught to debug plugins on the device remotely, but I can't find this feature in the new Xcode version. Does it exist In the new Xcodes? https://developer.apple.com/library/archive/technotes/tn2108/_index.html#//apple_ref/doc/uid/DTS40007965-CH1-SECCONFIGXCODE

I am building simple command-line programs in C. When I run LLDB on the command line on any such executable , even though I set a breakpoint in main, LLDB always runs to termination and reports an error. Below is an example: ~ % clang -Wall -g prog.c -o prog aviram@csaamdS278stma ~ % lldb prog (lldb) target create "prog" Current executable set to '/Users/aviram/prog' (x86_64). (lldb) breakpoint set --name main Breakpoint 1: where = progmain + 15 at prog.c:73:21, address = 0x0000000100003ebf (lldb) run Process 99926 launched: '/Users/aviram/prog' (x86_64) Process 99926 exited with status = -1 (0xffffffff) lost connection (lldb) ` Note that it says "lost connection" even though I am _ remote debugging. This happens with every executable I build._ Details: 2019 MacBook Pro (x86_64, Sonoma); Apple Clang 12.0.0 (downloaded with Xcode 15.0.1). Why is this happening and what can I do to debug my program (for real) using LLDB from the command line? Thanks.

As I was watching WWDC19 Session: "LLDB: beyond "po" " I got confused about "p" command. In the session there was a following example to show how "p" command works: // Struct for demonstration purposes struct Trip { var name: String var destinations: [String] let cruise = Trip ( name: "Mediterranean Cruise" destinations: ["Sorrento", "Capri", "Taormina"]) Using "p" to get info about cruise instance: (lldb) p cruise (Travel.Trip) $R0 = { name = "Mediterranean Cruise" destinations = 3 values { [0] = "Sorrento" [1] = "Capri" [2] = "Taormina" } } I was following along and wrote the same code. But the output from LLDB turned out to be different: (lldb) p cruise (LLDB_Apple_Session_FollowAlong.Trip) { name = "Mediterranean Cruise" destinations = 3 values { [0] = "Sorrento" [1] = "Capri" [2] = "Taormina" } } As you can see LLDB didn't create a global variable R0 which I could later use in my debugging session and that seemed strange to me. Then the presenter said the following: "p" is just an alias for the "expression" command. So, I tried to use the "expr" command to see if they're actually the same and they turned out to be different commands. The output I got from "expr" was the one I expected from "p": (lldb) expr cruise (LLDB_Apple_Session_FollowAlong.Trip) $R0 = { name = "Mediterranean Cruise" destinations = 3 values { [0] = "Sorrento" [1] = "Capri" [2] = "Taormina" } } Finally, my question is: Am I wrong somewhere or did something change in LLDB regarding "p" and "expr" commands and if so, where could I get more information about the changes?

xcrun devicectl has support for installing and launching apps but does it support launching a debugserver? I've tried xcrun devicectl device process launch /usr/libexec/debugserver to no avail. Is there something I'm missing or perhaps another tool that would let me start a debugserver from command line?

We've got hundreds of crashes in our SwiftUI app which we think are "silent" crashes as there are no complaints from clients and yet - it happens on the main thread in the foreground so I'm not completely sure. The annoying thing is that we have no idea by the stack trace what is causing this issue, I feel helpless as this is causing some very loud noise through management and honestly - myself who wants to have this noise cleared. this particular crash is the highest impact (one of a few different weird crashes in our app without clear stack trace) 0 SwiftUI 0x895d90 OUTLINED_FUNCTION_2 + 836 1 SwiftUI 0x895da8 OUTLINED_FUNCTION_2 + 860 2 SwiftUI 0x1329880 OUTLINED_FUNCTION_2 + 424 3 SwiftUI 0x6806c OUTLINED_FUNCTION_441 + 584 4 SwiftUI 0x481b0 OUTLINED_FUNCTION_194 + 544 5 UIKitCore 0x1b7194 -[UIViewController removeChildViewController:notifyDidMove:] + 128 6 UIKitCore 0x77d6e8 -[UINavigationController removeChildViewController:notifyDidMove:] + 80 7 UIKitCore 0x205224 -[UIViewController dealloc] + 768 8 UIKitCore 0x1036c -[UINavigationController viewDidDisappear:] + 372 9 UIKitCore 0xd9c4 -[UIViewController _setViewAppearState:isAnimating:] + 1012 10 UIKitCore 0x46e61c -[UIViewController __viewDidDisappear:] + 136 11 UIKitCore 0x7ec024 __64-[UIViewController viewDidMoveToWindow:shouldAppearOrDisappear:]_block_invoke_3 + 44 12 UIKitCore 0x1a3f24 -[UIViewController _executeAfterAppearanceBlock] + 84 13 UIKitCore 0x1a3e68 -[_UIAfterCACommitBlock run] + 72 14 UIKitCore 0x1a3d9c -[_UIAfterCACommitQueue flush] + 176 15 UIKitCore 0x1a3ca8 _runAfterCACommitDeferredBlocks + 496 16 UIKitCore 0x3f530 _cleanUpAfterCAFlushAndRunDeferredBlocks + 108 17 CoreFoundation 0x43564 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 18 CoreFoundation 0xabd9c __CFRunLoopDoBlocks + 368 19 CoreFoundation 0x7bbbc __CFRunLoopRun + 856 20 CoreFoundation 0x80ed4 CFRunLoopRunSpecific + 612 21 GraphicsServices 0x1368 GSEventRunModal + 164 22 UIKitCore 0x3a23d0 -[UIApplication _run] + 888 23 UIKitCore 0x3a2034 UIApplicationMain + 340 24 SwiftUI 0x1d1014 OUTLINED_FUNCTION_895 + 2420 25 SwiftUI 0x13216c block_copy_helper.1 + 388 26 SwiftUI 0x11b4bc OUTLINED_FUNCTION_901 + 2868 Number 27 will be our app's Main function and that it - no other trace of our apps code. Firebase is saying this happens 100% on iOS 16 only and always on the foreground. How can I get to the bottom of this? how can I debug such a crash?

HI devs, help me please, i want to debug Big Sur kernel on inter-based macbook from Monterey on m1, i have installed KDK_11.6.4_20G417.kdk in Monterey system on m1 macmini, then launch lldb, have created target and got this message : WARNING! Python version 3 is not supported for xnu lldbmacros. (lldb) target create /Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel warning: 'kernel' contains a debug script. To run this script in this debug session:   command script import "/Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/Python/kernel.py" To run all discovered debug scripts in this session:   settings set target.load-script-from-symbol-file true Current executable set to '/Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel' (x86_64). (lldb) settings set target.load-script-from-symbol-file true ############################## WARNING! Python version 3 is not supported for xnu lldbmacros. Please restart your debugging session with the following workaround defaults write com.apple.dt.lldb DefaultPythonVersion 2 ############################## Loading kernel debugging from /Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/Python/kernel.py LLDB version lldb-1300.0.42.3 Swift version 5.5.2-dev settings set target.process.python-os-plugin-path "/Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/Python/lldbmacros/core/operating_system.py" settings set target.trap-handler-names hndl_allintrs hndl_alltraps trap_from_kernel hndl_double_fault hndl_machine_check _fleh_prefabt _ExceptionVectorsBase _ExceptionVectorsTable _fleh_undef _fleh_dataabt _fleh_irq _fleh_decirq _fleh_fiq_generic _fleh_dec command script import "/Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/Python/lldbmacros/xnu.py" error: module importing failed: Traceback (most recent call last):  File "<string>", line 1, in <module>  File "/Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/Python/lldbmacros/xnu.py", line 123   print "Execution interrupted by user"      ^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Execution interrupted by user")? settings set target.process.optimization-warnings false How can i solve this problem? lldb linked with python 3, but kdk uses python 2, also command line tools version 12.5.1 which uses python 2 i can not install on monterey too.

I am using Xcode 13 on a Macbook Pro (Intel/2019) with macOS Big Sur 11.6 I am building and launching the app on a connecting iPhone X running iOS 15.0, I am also running a UI test suite based on XCUITest while I do that. The app takes extremely long to launch (2+ minutes), then it sits on the splash screen for another 2-3 minutes. Meanwhile, Xcode shows the alert attached: I have 2 questions: Is this a widespread Xcode 13 / iOS 15 issue? Can someone please explain what the message in the alert means "LLDB is likely reading from device memory to resolve symbols"? Is there anything I can do to reduce or avoid this wait?

similiar to Error when debugging: Cannot creat… | Apple Developer Forums - https://developer.apple.com/forums/thread/651375 Xcode 12 beta 1 po command in de… | Apple Developer Forums - https://developer.apple.com/forums/thread/651157 which do not resolve this issue that I am encountering Description of problem I am seeing an error which prevents using lldb debugger on Swift code/projects. It is seen on any Swift or SwiftUI project that I've tried. This is the error displayed in lldb console when first breakpoint is encountered: Cannot create Swift scratch context (couldn't create a ClangImporter)(lldb)  Xcode Version 12.3 (12C33) macOS Big Sur Intel M1 Troubleshooting I originally thought this was also working on an Intel Mac running Big Sur/Xcode 12.3, but was mistaken. Using my customized shell environment on the following setups, I encounter the same couldn't create a ClangImporter. M1 Mac mini, main account (an "Admin" account) same M1 Mac mini, new "dev" account (an "Admin" account) Intel MBP, main account They are all using an Intel Homebrew install, and my customized shell environment if that provides a clue? I captured some lldb debugging info by putting expr types in ~/.lldbinit but the outputs were basically identical (when discounting scratch file paaths and memory addresses) compared to the "working clean" account log (described below) log enable -f /tmp/lldb-log.txt lldb expr types works in a "clean" user account I created a new, uncustomized "Standard" testuser account on the M1 Mac mini, and launched the same system Xcode.app. There was no longer this error message, and was able to inspect variables at a swift program breakpoint in Swift context, including po symbol. Impact Effectively this makes the debugger in Swift on Xcode projects on my systems essentially unable to inspect Swift contexts' state.

There have been occasional questions about remote debugging. Unfortunately I see a couple of them which were reasonable basic questions got no answer at all. I will try this again. A couple questions had some mention of lldb server. In some cases clearly the people asking the questions already knew a bit about remote debugging. Yet I can find no documentation about it.Does XCode or other tools that will work with XCode support debugging over the internet? If so what are the reqirements re XCode version and macOS version, whether the client and server can have unmatched versions, etc.?My immediate need (without extra steps) is to debug a process running on Sierra (no XCode installed yet) from a development system running XCode 7.3.1 under El Capitan.The need for remote debugging is to be able to diagnose crashes that don't happen on my development systems. There have also been questions concerning crash logs, but crash logs are of limited use unless the crash can be opened into a debugger with full ability to examine the stack and local variables.Thanks in advance!