The LLDB command-line debugger provides underlying debugging services for development on all Apple platforms.

Posts under LLDB tag

34 Posts
Sort by:

Post

Replies

Boosts

Views

Activity

mac-to-mac remote debugging
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!
4
1
3.7k
Dec ’23
Debugging Big Sur kernel on inter-based macbook from Monterey on m1
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.
4
0
2.3k
Mar ’24
A bug in Xcode lldb debugger for swift
In some particular situation, Xcode debugger or lldb cli cannot correctly extract some value that returned by a async throw function and handled by guard let try?. Here is the minimum example: import Dispatch func test() async throws -> [Int] {   return [369] } let group = DispatchGroup() group.enter() let task = Task {   guard let res = try? await test() else { return }   print(res)   group.leave() } group.wait() If added a break point at print(res), the debugger cannot show the value of res. Due to forum limitation, I cannot paste a screenshot here... if use p res or po res at lldb cli, it shows: (lldb) p res error: expression failed to parse: error: <EXPR>:3:1: error: cannot find 'res' in scope res ^~~ (lldb) po res error: expression failed to parse: error: <EXPR>:3:1: error: cannot find 'res' in scope res ^~~ If test() returns a dict, or a costom struct, the issue retains. But if returned a trivial value like Int, it acts normally. Also, if remove the guard statement, make res a optional value(use let res = try? await test()), debugger can extract the value. Above results are compiled and run in this environment: Swift 5.6.1 Xcode 13.4.1 (13F100) lldb-1316.0.9.46 macOS 12.4 x86_64 arch
5
3
3.9k
Jul ’23
Breakpoints not resolving on Xcode 14 (Turn to outlines when app is run)
We are running into an issue where breakpoints are not resolving on Xcode 14 (The same break points on Xcode 13.4.1 are working fine). They change to an outline when we run our app I have tried all the usual fixes Cleaned the build Cleaned Derived data Restarted Xcode Restarted the machine Re-cloned the repo to see if starting fresh helps I have also tried Removing all symbol stripping Ensuring the DSYM is getting generated and is loaded in the debugger Removing all optimization options Tried the Xcode 14.1 beta What's really strange is the break points will work occasionally and will work for a few runs and then stop working again. Does anyone have any suggestions?
4
3
3.0k
Aug ’23
Xcode 14.2+: lldb-rpc-server has crashed.
I don't know when this started but it's basically brought my development to a standstill. I know it worked fine in macOS 13.2.1, though I didn't try Xcode 14.3 RC 2 in 13.2.1. Basically, Xcode 14.3 RC 2 (14E222b) and also Xcode 14.2 (14C18) (which had been stable up till now) are both unable to launch the app in debug mode. As soon as the launched/debugged app finally starts, the following is printed to Xcode's console: Message from debugger: The LLDB RPC server has crashed. You may need to manually terminate your process. The crash log is located in ~/Library/Logs/DiagnosticReports and has a prefix 'lldb-rpc-server'. Please file a bug and attach the most recent crash log. The crash log is always the same. The full log is at https://gist.github.com/NSGod/5e194900bd6f5a9ac9328b936a26037e. There seems to be an infinite loop in thread 6: Thread 6 Crashed:: &lt;lldb.process.internal-state(pid=30877)&gt; 0 LLDB 0x12030cfb4 ParseTrieEntries(....) + 20 1 LLDB 0x12030d653 ParseTrieEntries(....) + 1715 After I initially encountered this issue in Xcode 14.3 RC 2 (14E222b) with my business project, I tried creating a new Cocoa app using Xibs and Objective-C and still encountered the problem in that project. I've cleaned out the build folders, etc. but that made no difference. I opened both my business project and a new project in Xcode 14.2 (14C18) but saw no difference (it still crashes). I also tried in a new user account using both versions of Xcode but they both crash. Could having Python 3.10 and 3.11 installed through MacPorts anything to do with it (I noticed Python 3.9 in the binary images, but I'm not sure). Any ideas?
11
1
3.4k
Oct ’23
Impossible to use $R* variables after `continue` command
I’m trying to use the allocated variables given after p self ($R1 for instance) but after resuming the process and then pausing it again, I cannot access to $R1. (lldb) p self (Signals.MainContainerViewController) $R1 = 0x000000012ba19dc0 { ... (lldb) po $R1 <Signals.MainContainerViewController: 0x12ba19dc0> (lldb) c Process 88944 resuming (lldb) expression -O -l swift -- $R1 warning: Module "/usr/lib/system/libsystem_kernel.dylib" uses triple "arm64-apple-macosx13.4.0", which is not compatible with the target triple "arm64-apple-ios16.0.0-simulator". Enabling per-module Swift scratch context. error: expression failed to parse: error: <EXPR>:3:1: error: cannot find '$R1' in scope $R1 ^~~ (lldb) Does someone have an idea? macOS: 13.4.1 (22F82) Xcode Version 14.3.1
5
1
1.3k
Sep ’23
Unable to properly attach to executable with lldb running under Rosetta
I'm trying to attach with lldb to a x64 process running under Rosetta, attachment itself succeeded but lldb is unable to load target neither it's modules. And getting this output: (lldb) process attach --pid 20586 Process 20586 stopped * thread #1, stop reason = signal SIGSTOP frame #0: 0x00007ff813a1d1ee -> 0x7ff813a1d1ee: jae 0x7ff813a1d1f8 0x7ff813a1d1f0: movq %rax, %rdi 0x7ff813a1d1f3: jmp 0x7ff813a18cdb 0x7ff813a1d1f8: retq Target 0: (No executable module.) stopped. Architecture set to: x86_64-apple-macosx-. (lldb) target modules list error: the target has no associated executable images A few weeks ago I had the same problem, but some combination of actions like rebuilding deleting and redownloading binaries and some other unknown magic fixed this behaviour. And today I stumbled upon this problem again, and same actions does not make any effect. Attaching to process works in general (event to processes running under Rosetta), but this specific process I want to debug is causing troubles. This is what successful attachment looks like: (lldb) process attach --pid 20576 warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not read from the host's in-memory shared cache. This will likely reduce debugging performance. Process 20576 stopped * thread #1, name = 'CrRendererMain', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00007ff813a185b2 libsystem_kernel.dylib`mach_msg2_trap + 10 libsystem_kernel.dylib`mach_msg2_trap: -> 0x7ff813a185b2 <+10>: retq 0x7ff813a185b3 <+11>: nop libsystem_kernel.dylib`macx_swapon: 0x7ff813a185b4 <+0>: movq %rcx, %r10 0x7ff813a185b7 <+3>: movl $0x1000030, %eax ; imm = 0x1000030 Target 0: (Electron Helper (Renderer)) stopped. Executable module set to "/Users/mb/work/positron/node_modules/electron/dist/Electron.app/Contents/Frameworks/Electron Helper (Renderer).app/Contents/MacOS/Electron Helper (Renderer)". Architecture set to: x86_64-apple-macosx-. To give a bit more context my MacOS version is 13.14.1 on MacBook Pro with M2 chip.
2
0
921
Jul ’23
Unknown Crash - OUTLINED_FUNCTION_2
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?
9
2
1.6k
Dec ’23
XCode 15.0 debugging issue - variables view shows empty containers
Hello, I am facing an issue when debugging cpp code through the XCode after updating to XCode 15.0. During debugging, in a variables watch view, it is shown for the collections (let's take std::vector as an example) that its size is 0 even if it is not. If I add it as an expression to watch, it is fine. Also if I print it in lldb console, it is also fine. Any thoughts on this?
0
0
652
Oct ’23
Debug a process by hand from a c program on an Apple Silicon CPU
Hello, My purpose is to understand how macOS works. Here is what i've done: I have wrote a c program on a M1 CPU with this lines: printf("Before breakpoint\n"); asm volatile("brk #0"); printf("After breakpoint\n"); When i run this program with lldb, a breakpoint is hit on the second line. So i suppose lldb is writing a "brk #0" instruction when we put a breakpoint manually. I can't continue to next line with lldb "c" command. PC stays on the brk instruction. I need to manually set PC to next instruction in lldb. Now, what i want to do is to create my own debugger. (I want to understand how lldb works). I have managed to ptrace the target program and i was able to catch an event with waitpid when "brk #0" is hit. But i don't know how i can increase PC value and continue execution because i can't do this on Silicon CPU: ptrace(PTRACE_GETREGS, child_pid, NULL, &amp;regs); ptrace(PTRACE_SETREGS, child_pid, NULL, &amp;regs); kill(child_pid, SIGCONT); So my question is: How does lldb managed to change ARM64 registers of a remote process ? Thanks
2
0
739
Nov ’23
LLDB doesn’t stop on SIGABRT (assert) with x86 executable on Apple ARM
Hello. I am currently developing a C++ application for x86_64 using XCode, and I am experiencing the same problem as described in the following link. https://discourse.llvm.org/t/lldb-doesnt-stop-on-sigabrt-assert-with-x86-executable-on-apple-arm/69749/1 Due to this bug, when the application crashes, it is difficult to tell which source code caused the crash, and this is reducing our development efficiency. How can this be fixed? Thank you in advance for your help.
2
0
572
Nov ’23
Confused about LLDB's "p" and "expr" commands
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?
2
0
608
Dec ’23
LLDB always exits abnormally on local code
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.
3
0
740
Dec ’23
Xcode 15.1 is adding extra lines in between print() statements, sometimes
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.
4
1
931
Dec ’23
Help needed with lldb - attach to Mac after a kernel panic
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)
2
0
598
Jan ’24