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

Posts under LLDB tag

32 Posts

Post

Replies

Boosts

Views

Activity

LLDB Cannot Load ODBC Driver Due to Sandbox Restrictions - How to Debug
I'm developing a macOS console application that uses ODBC to connect to PostgreSQL. The application works fine when run normally, but fails to load the ODBC driver when debugging with LLDB(under root works fine as well). Error Details When running the application through LLDB, I get this sandbox denial in the system log (via log stream): Error 0x0 0 0 kernel: (Sandbox) Sandbox: logd_helper(587) deny(1) file-read-data /opt/homebrew/lib/psqlodbcw.so The application cannot access the PostgreSQL ODBC driver located at /opt/homebrew/lib/psqlodbcw.so(also tried copy to /usr/local/lib/...). Environment macOS Version: Latest Sequoia LLDB: Using LLDB from Xcode 16.3 (/Applications/Xcode16.3.app/Contents/Developer/usr/bin/lldb) ODBC Driver: PostgreSQL ODBC driver installed via Homebrew Code Signing: Application is signed with Apple Development certificate What is the recommended approach for debugging applications that need to load dynamic libraries? Are there specific entitlements or configurations that would allow LLDB to access ODBC drivers during debugging sessions? Any guidance would be greatly appreciated. Thank you for any assistance!
1
0
145
5d
tvOS 26 + Xcode 26 debugger won't launch
I have been using tvOS 18 and Xcode 26 all summer without issue but since updating the tv to the latest tvOS 26 beta I am now unable to attach to debug builds. When using the Run button in Xcode the build completes, the tv screen goes black and then I see a warning in Xcode: Launching "App Name" is taking longer than expected. Do you want to continue to wait? LLDB is likely reading from device memory to resolve symbols. If I continue to wait after around 5 mins, in the Xcode console, I see: warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not find the on-disk shared cache for this device. This will likely reduce debugging performance. But the process on the tv hangs indefinately. Hitting stop in Xcode disconnects the debugger but the app then finishes launching successfully on the TV. Trying to use "Debug > Attach to process > [App Name]" once it is running also just hangs the app and waits until stopped. When stopping the hung debugger I see an Xcode error with the following: Could not attach to pid : “1222” Domain: IDEDebugSessionErrorDomain Code: 3 Failure Reason: internal error User Info: { DVTErrorCreationDateKey = "2025-09-01 09:51:54 +0000"; DVTRadarComponentKey = 855031; IDERunOperationFailingWorker = DBGLLDBLauncher; RawUnderlyingErrorMessage = "Xcode has killed the LLDB RPC server to allow the debugger to detach from your process. You may need to manually terminate your process."; } -- Event Metadata: com.apple.dt.IDERunOperationWorkerFinished : { "device_identifier" = "00008110-000240CE1A87801E"; "device_isCoreDevice" = 1; "device_isWireless" = 1; "device_model" = "AppleTV14,1"; "device_osBuild" = "26.0 (23J5348a)"; "device_osBuild_monotonic" = 2309534800; "device_os_variant" = 1; "device_platform" = "com.apple.platform.appletvos"; "device_platform_family" = 4; "device_reality" = 1; "device_thinningType" = "AppleTV14,1"; "device_transport" = 2; "launchSession_schemeCommand" = Run; "launchSession_schemeCommand_enum" = 1; "launchSession_targetArch" = arm64; "launchSession_targetArch_enum" = 6; "operation_duration_ms" = 76122; "operation_errorCode" = 3; "operation_errorDomain" = IDEDebugSessionErrorDomain; "operation_errorWorker" = DBGLLDBLauncher; "operation_error_reportable" = 1; "operation_name" = IDERunOperationWorkerGroup; "param_consoleMode" = 0; "param_debugger_attachToExtensions" = 0; "param_debugger_attachToXPC" = 1; "param_debugger_type" = 3; "param_destination_isProxy" = 0; "param_destination_platform" = "com.apple.platform.appletvos"; "param_diag_MainThreadChecker_stopOnIssue" = 0; "param_diag_MallocStackLogging_enableDuringAttach" = 0; "param_diag_MallocStackLogging_enableForXPC" = 0; "param_diag_allowLocationSimulation" = 0; "param_diag_checker_mtc_enable" = 0; "param_diag_checker_tpc_enable" = 0; "param_diag_gpu_frameCapture_enable" = 0; "param_diag_gpu_shaderValidation_enable" = 0; "param_diag_gpu_validation_enable" = 1; "param_diag_guardMalloc_enable" = 0; "param_diag_memoryGraphOnResourceException" = 0; "param_diag_queueDebugging_enable" = 1; "param_diag_runtimeProfile_generate" = 0; "param_diag_sanitizer_asan_enable" = 0; "param_diag_sanitizer_tsan_enable" = 0; "param_diag_sanitizer_tsan_stopOnIssue" = 0; "param_diag_sanitizer_ubsan_enable" = 0; "param_diag_sanitizer_ubsan_stopOnIssue" = 0; "param_diag_showNonLocalizedStrings" = 0; "param_diag_viewDebugging_enabled" = 1; "param_diag_viewDebugging_insertDylibOnLaunch" = 1; "param_install_style" = 2; "param_launcher_UID" = 2; "param_launcher_allowDeviceSensorReplayData" = 0; "param_launcher_kind" = 0; "param_launcher_style" = 99; "param_launcher_substyle" = 256; "param_lldbVersion_component_idx_1" = 0; "param_lldbVersion_monotonic" = 170300300002; "param_runnable_appExtensionHostRunMode" = 0; "param_testing_launchedForTesting" = 0; "param_testing_suppressSimulatorApp" = 0; "param_testing_usingCLI" = 0; "sdk_canonicalName" = "appletvos26.0"; "sdk_osVersion" = "26.0"; "sdk_platformID" = 3; "sdk_variant" = appletvos; "sdk_version_monotonic" = 2309534400; } -- System Information macOS Version 26.0 (Build 25A5349a) Xcode 26.0 (24208.14) (Build 17A5305k) Timestamp: 2025-09-01T10:51:54+01:00 I have another AppleTV still running on tvOS 18 and builds continue to run and attach fine there. I've tried rebooting the 26 beta AppleTV but I'm at a bit of a loss what else to try?
1
0
219
2w
lldb-dap closes connection
If I build an x64 binary on my M4 Mini, when I try to debug it using Visual Studio remote debugging the connection is closed, which means I cannot debug my code in x64 mode. I need to be able to do this as I have architecture specific code. I have Rosetta installed. FWIW I have the same issue with lldb-mi :( David
3
0
86
Jul ’25
No KDKs available for macOS 26.0 Developer Beta 2 and later
As of now, there is no Kernel Debug Kit (KDK) available for macOS 26.0 Developer Betas after the first build. Kernel Debug Kits are crucial for understanding panics and other bugs within custom Kernel Extensions. Without the KDK for the corresponding macOS version, tools like kmutil fail to recognize a KDK and certain functions are disabled. Additionally, as far as I am aware, a KDK for one build of macOS isn't able to be used on a differing build. Especially since this is a developer beta, where developers are updating their software to function with the latest versions of macOS, I'd expect a KDK to be available for more than one build.
2
0
294
Jul ’25
lldbinit file in Xcode
My ultimate aim is to be able to prevent Xcode from single-stepping into certain C++ functions - just as it does not single-step into std:: functions. It appears to be possible to arrange this by making a more elaborate version of an LLDB setting such as this: target.process.thread.step-avoid-regexp (regex) = ^std:: It also appears to be possible to put this setting into an "lldbinit" file so that LLDB (within Xcode) picks up the setting automatically when a debugging session starts. What I do not know is this: Where do I put the "lldbinit" file inside my project? What Xcode project or target settings need to be made to tell Xcode where to find my "lldbinit" file and use it?
2
0
123
Jun ’25
Cannot debug app-extension-safe frameworks in main app
The code in my app is split into frameworks that I can use both from my main app and its app extensions. In order to use the frameworks inside the app extension, I need to build them with the Xcode build setting Require Only App-Extension-Safe API set to Yes. When I do that, debugging framework code in my main app no longer works properly. I can set a breakpoint, but any attempt to print a value via p or po will give a set of errors like the following: error: module file /Users/.../Library/Developer/Xcode/DerivedData/...-daqfgouagvlkudfebrmzrurogmld/Build/Intermediates.noindex/SwiftExplicitPrecompiledModules/_errno-B8I5WSZMM09RXHYLYEWSC1BLE.pcm cannot be loaded due to a configuration mismatch with the current compilation error: Objective-C App Extension was enabled in PCH file but is currently disabled How do I fix this?
1
0
127
Jun ’25
LLDB is invoking Xcode to display source code all of a sudden. How to switch back?
I've cross posted this at https://stackoverflow.com/q/79647300/6230282 Basically, I use command line and emacs app to develop on daily basis, but all of a sudden, LLDB is invoking Xcode to display source code for me, instead of printing them in command line. How do I switch back? Or alternatively, can I set a custom editor for LLDB? (lldb) version lldb-1700.0.9.502 Apple Swift version 6.1.2 (swiftlang-6.1.2.1.2 clang-1700.0.13.5) About Xcode: Version 16.4 (16F6)
1
0
112
Jun ’25
Xcode JSONDecoder playground fails with 'The LLDB RPC server has crashed.
If I create a playground project that uses a JSONDecoder I get the following error. The LLDB RPC Server has crashed. The crash log is located at ~/Library/Logs/DiagnosticReports and has a prefix 'lldb-rpc-server'. Please file a bug and attach the most recent crash log. I have raised feedback for this, FB17702087, but I hope that there may be a workaround. The code I am using to try and get this to work is from The Apple Developer Documentation - JSON Decoder var greeting = "JSON Test 3" struct GroceryProduct: Codable { var name: String var points: Int var description: String? } let json = """ { "name": "Durian", "points": 600, "description": "A fruit with a distinctive scent." } """.data(using: .utf8)! let decoder = JSONDecoder() let product = try decoder.decode(GroceryProduct.self, from: json) print(product.name) // Prints "Durian" A screenshot of the playground showing the error The crash log (the file type has been changed to txt as ips file types cannot be selected for upload. lldb-rpc-server-2025-05-28-140832.txt
0
0
65
May ’25
[Help] Xcode device debugging of iOS 18.4 / 18.5 is very slow, and it is suspected to be stuck in the stage of loading dynamic libraries in debugserver
Environment Xcode version: Xcode 16.0 iOS device system version: iOS 18.4 / 18.5 Problem description When debugging iOS 18.4/18.5 on a real device, the App starts very slowly after clicking Run, usually taking 2-3 minutes, which is much slower than iOS 18.3. It manifests as Xcode staying in the Launch stage for a long time, and the application stuck in the opening screen interface. Start the APP first, then attach the process, and this problem will not exist Location process Use lldb to enable logs log enable gdb-remote packets After observing the logs, it was found that: The jam mainly occurs when processing two data packets: jGetLoadedDynamicLibrariesInfos and qProcessInfo These two commands involve dynamic library loading information and process meta information, and the response time is much higher than the normal level, far exceeding other gdb-remote instructions Use Instruments / Profiler to analyze: The CPU peak of the real machine debugserver is concentrated in the dynamic library information loading process of _dyld_process_info_create Is there a way to deploy a modified debugserver on the real machine to further locate the problem How to enable and view the debugsever log to further locate the problem
0
1
76
May ’25
LLDB error: type for self cannot be reconstructed: type for typename
All is fine in Xcode15, no LLDB errors whatsoever, but in Xcode16 I can't get any variable displayed in the console because of the following error: error: type for self cannot be reconstructed: type for typename "$......." was not found (cached) error: Couldn't realize Swift AST type of self. Hint: using `v` to directly inspect variables and fields may still work. I've checked the output of swift-healthcheck and there are several messages like this: SwiftASTContextForExpressions(module: "ROA", cu: "ROA+ViewLayer.swift")::LoadOneModule() -- Missing Swift module or Clang module found for "UIKit", "imported" via SwiftDWARFImporterDelegate. Hint: Register Swift modules with the linker using -add_ast_path. I added -add_ast_path to the OTHER_LDFLAGS in the faulty module's build settings but no luck. How can I debug my project in Xcode16?
15
2
1.9k
May ’25
Empty dSYM file detected & Error: type for self cannot be reconstructed: type for typename
I'm pulling my hair out here with this new Xcode 16, it complains that my app's dSYM is empty though it's clearly not, it's about 25MB. I'm working on a project using an internal static library, everything is built inhouse using swift, we own all the source code. It worked just fine until the other week, when I updated the Xcode, and now I can't debug anything. I keep getting "type for self cannot be reconstructed" when I run "po self.some_property". Why is that? The Debug information Format is set to DWARF with dSYM File for both the executable and lib projects. I've been a Unix guy since before I knew myself and I enjoy fixing things myself, down to bare metal, but man, this bug is driving me crazy. Is it even a bug?? It's the first time in more than 15 years since I started coding on Mac and iPhone when a bug has defeated me. I was always able to fix things using just the documentation and google, but the Apple toolchain is getting worse and worse nowadays. I remember the time when Apple made the complicated things simple, now they make the simple things complicated :( I just split the static lib from the main project one year ago, because of the ridiculously long build time. Should I merge back all the code in a single project? Something seems wrong to me. So I created this account to ask the masters. How can I get back my debug info (and sanity)? Using Xcode 15 is not an option because it doesn't run on Sequoia.
1
2
984
May ’25
error: type for self cannot be reconstructed: type for typename
Hi, i have met error below when i tried to po one attributes of an instance in my Xcode lldb: error: type for self cannot be reconstructed: type for typename "$xxxxx" was not found (cached) error: Couldn't realize Swift AST type of self. Hint: using `v` to directly inspect variables and fields may still work. Is there anybody met the same error before? I urgently want to know why this happen and how to fix this issue. My macOS Version is Sequoia v15.0.1, Xcode16.0. This problem showed after i upgraded my macOS and Xcode version.
23
36
7k
May ’25
LLDB RPC server crash in Xcode 16.3
Created a new project in Xcode 16.3. While adding breakpoints app is crashing every time in Xcode and playground both. Tried with swift 5 and swift 6 getting same error. Crash reason : Couldn't find the Objective-C runtime library in loaded images. Message from debugger: The LLDB RPC server has crashed. You may need to manually terminate your process lldb-rpc-server-2025-04-14-092736.txt
4
6
315
May ’25
Cannot evaluate variables in xCode 16.2 debugger
When I try to look at any variable in the debugger, I get a bunch of errors complaining about inability to find a file in a location that should not exist on my machine... I just upgraded form xCode 15.2, which worked fine, but now I basically cannot debug. Who is this liangchenying? It's almost like the new version was shipped with some developer's paths hard-coded in the configuration. (lldb) po [tableNumberTxt.text integerValue] warning: (arm64) /Users/stevedavison/lineskip_dev/POS/SNBC/POSSDKForIOSLIB.a(PortIO.o) 0x00000000000004a7: unable to locate module needed for external types: /Users/liangchenying/Library/Developer/Xcode/DerivedData/POSSDKForIOSLIB-bmkvfovoxsbzudehquaovgmnnooe/Build/Intermediates/PrecompiledHeaders/POSSDKForIOSLIB-Prefix-cfcbmooemqunxmehfbebereyakbw/POSSDKForIOSLIB-Prefix.pch.pch error: '/Users/liangchenying/Library/Developer/Xcode/DerivedData/POSSDKForIOSLIB-bmkvfovoxsbzudehquaovgmnnooe/Build/Intermediates/PrecompiledHeaders/POSSDKForIOSLIB-Prefix-cfcbmooemqunxmehfbebereyakbw/POSSDKForIOSLIB-Prefix.pch.pch' does not exist Debugging will be degraded due to missing types. Rebuilding the project will regenerate the needed module files.warning: (arm64) /Users/stevedavison/lineskip_dev/POS/SNBC/POSSDKForIOSLIB.a(WIFIPort.o) 0x000000000000171c: unable to locate module needed for external types: /Users/liangchenying/Library/Developer/Xcode/DerivedData/POSSDKForIOSLIB-bmkvfovoxsbzudehquaovgmnnooe/Build/Intermediates/PrecompiledHeaders/POSSDKForIOSLIB-Prefix-cfcbmooemqunxmehfbebereyakbw/POSSDKForIOSLIB-Prefix.pch.pch error: '/Users/liangchenying/Library/Developer/Xcode/DerivedData/POSSDKForIOSLIB-bmkvfovoxsbzudehquaovgmnnooe/Build/Intermediates/PrecompiledHeaders/POSSDKForIOSLIB-Prefix-cfcbmooemqunxmehfbebereyakbw/POSSDKForIOSLIB-Prefix.pch.pch' does not exist Debugging will be degraded due to missing types. Rebuilding the project will regenerate the needed module files.warning: (arm64) /Users/stevedavison/lineskip_dev/POS/SNBC/POSSDKForIOSLIB.a(SimpleLogger.o) 0x00000000000009b9: unable to locate module needed for external types: /Users/liangchenying/Library/Developer/Xcode/DerivedData/POSSDKForIOSLIB-bmkvfovoxsbzudehquaovgmnnooe/Build/Intermediates/PrecompiledHeaders/POSSDKForIOSLIB-Prefix-cfcbmooemqunxmehfbebereyakbw/POSSDKForIOSLIB-Prefix.pch.pch error: '/Users/liangchenying/Library/Developer/Xcode/DerivedData/POSSDKForIOSLIB-bmkvfovoxsbzudehquaovgmnnooe/Build/Intermediates/PrecompiledHeaders/POSSDKForIOSLIB-Prefix-cfcbmooemqunxmehfbebereyakbw/POSSDKForIOSLIB-Prefix.pch.pch' does not exist Debugging will be degraded due to missing types. Rebuilding the project will regenerate the needed module files.warning: (arm64) /Users/stevedavison/lineskip_dev/POS/SNBC/POSSDKForIOSLIB.a(POSCommand.o) 0x00000000000035bd: unable to locate module needed for external types: /Users/liangchenying/Library/Developer/Xcode/DerivedData/POSSDKForIOSLIB-bmkvfovoxsbzudehquaovgmnnooe/Build/Intermediates/PrecompiledHeaders/POSSDKForIOSLIB-Prefix-cfcbmooemqunxmehfbebereyakbw/POSSDKForIOSLIB-Prefix.pch.pch error: '/Users/liangchenying/Library/Developer/Xcode/DerivedData/POSSDKForIOSLIB-bmkvfovoxsbzudehquaovgmnnooe/Build/Intermediates/PrecompiledHeaders/POSSDKForIOSLIB-Prefix-cfcbmooemqunxmehfbebereyakbw/POSSDKForIOSLIB-Prefix.pch.pch' does not exist Debugging will be degraded due to missing types. Rebuilding the project will regenerate the needed module files.warning: (arm64) /Users/stevedavison/lineskip_dev/POS/SNBC/POSSDKForIOSLIB.a(WIFIPortToFile.o) 0x00000000000004da: unable to locate module needed for external types: /Users/liangchenying/Library/Developer/Xcode/DerivedData/POSSDKForIOSLIB-bmkvfovoxsbzudehquaovgmnnooe/Build/Intermediates/PrecompiledHeaders/POSSDKForIOSLIB-Prefix-cfcbmooemqunxmehfbebereyakbw/POSSDKForIOSLIB-Prefix.pch.pch error: '/Users/liangchenying/Library/Developer/Xcode/DerivedData/POSSDKForIOSLIB-bmkvfovoxsbzudehquaovgmnnooe/Build/Intermediates/PrecompiledHeaders/POSSDKForIOSLIB-Prefix-cfcbmooemqunxmehfbebereyakbw/POSSDKForIOSLIB-Prefix.pch.pch' does not exist Debugging will be degraded due to missing types. Rebuilding the project will regenerate the needed module files.warning: (arm64) /Users/stevedavison/lineskip_dev/POS/SNBC/POSSDKForIOSLIB.a(POSSDK.o) 0x0000000000002432: unable to locate module needed for external types: /Users/liangchenying/Library/Developer/Xcode/DerivedData/POSSDKForIOSLIB-bmkvfovoxsbzudehquaovgmnnooe/Build/Intermediates/PrecompiledHeaders/POSSDKForIOSLIB-Prefix-cfcbmooemqunxmehfbebereyakbw/POSSDKForIOSLIB-Prefix.pch.pch error: '/Users/liangchenying/Library/Developer/Xcode/DerivedData/POSSDKForIOSLIB-bmkvfovoxsbzudehquaovgmnnooe/Build/Intermediates/PrecompiledHeaders/POSSDKForIOSLIB-Prefix-cfcbmooemqunxmehfbebereyakbw/POSSDKForIOSLIB-Prefix.pch.pch' does not exist Debugging will be degraded due to missing types. Rebuilding the project will regenerate the needed module files.7
4
0
150
May ’25
Xcode Debug Launch Extremely Slow on iOS 18.4 with Large Binary (~1GB)
After upgrading to iOS 18.4, I noticed that launching a debug build from Xcode becomes extremely slow. The same app with the same large debug binary (~1GB) launches normally on devices running iOS 18.3. This issue seems specific to iOS 18.4, possibly related to the way the OS handles large debug binaries or symbols during the launch process. Steps to Reproduce: Connect an iPhone running iOS 18.4 to a Mac with Xcode. Build and run an app using Xcode in Debug mode. Observe the extended launch time. Re-run the same process on another iPhone with iOS 18.3 — launch is fast. Expected Result: Debug launch should be fast and consistent across iOS versions. Actual Result: Debug launch is significantly slower on iOS 18.4 for large binaries (~1GB). Environment: Xcode version: 16.0 macOS version: 15.4 Device: iPhone [model] iOS version: 18.4 (problematic), 18.3 (no issue)
1
2
127
May ’25
Breakpoint on Runtime Issue os_log_fault_default_callback
The app stops on the breakpoint when "All Runtime Issues" is added. If I disable the breakpoint, the app runs normally. Is there a new project setting to avoid this breakpoint from being set. It does not appear to be a valid error. I am running Xcode 16.2. I edited the "Type" field in the breakpoint box. This occurs with the "System Frameworks" option only.
0
2
59
Apr ’25
A static lib/framework with dwarf info. Will leaking your private info?
When you build a static library that includes DWARF information, you may encounter error messages in the binary package generated by Xcodebuild. Upon examining the DWARF information with dwarfdump, you will find that any entries containing keywords like dir are all absolute paths specific to the publisher's computer. This is quite alarming, as it poses a risk of leaking private information. Additionally, when debugging an app, you can encounter consistent warning notes indicating that the referenced path addresses cannot be found. This is because the absolute path addresses generated during the 'xcodebuild' process reflect the paths from the computer used to build it. When distributing this to others, how can anyone access these paths? Has the design of the secondary linking process for DWARF considered the issues related to binary distribution? Are there existing solutions to address and handle privacy concerns? Is there a solution to allow the distributed DWARF files to be correctly recognized during compilation and debugging of the app? BTW: Incorrect paths can indeed affect LLDB's ability to load and debug the application effectively?
1
0
212
Mar ’25