I am trying to learn Metal development on my MacBook Pro M1 Pro (Sequoia 15.3.1) on Xcode Playground, but when I write these two lines of code: import Metal let device = MTLCreateSystemDefaultDevice()! I get the error The LLDB RPC server has crashed. Any ideas as to what I can do to solve this? I have rebooted the machine and reinstalled Xcode...

My app is running Compute Shaders that use non-uniform thread groups. When I run the app in the debugger with a simulator target the app crashes on encoder.dispatchThreads and the error message is: Dispatch Threads with Non-Uniform Threadgroup Size is not supported on this device. Previously the log output states that: Metal Shader Validation is unsupported for Simulator. However: When I stop the debugger and just run the app in the simulator without the debugger attached, the app just runs fine and does not crash. The SwiftUI Preview that also triggers the Compute Shader when preparing data also just runs fine without a crash. I can run and debug on a real device no problem - I just don't have all sizes available. Is there anything I need to check in my lldb/simulator configuration? It obviously does work, just the debugger cannot really deal with it? Any input would be nice as this really slows my down as I have to be extremely careful when debugging on the simulator.

The charging port of my iPhone may be damaged due to water, and it cannot be charged and transmitted data. It can only be charged wirelessly that does not support data transmission. However, since Xcode supports wireless debugging, I can continue to test my App. However, I recently changed to a new Mac, but there is no connection record with the iPhone in the new Mac, which makes it impossible to debug wirelessly. So I want to know how to realize wireless debugging on such a device without debugging records?

Here's a simple C++ program that echoes its arguments... #include <stdio.h> int main(int argc, char* argv[]) { for (int i=0; i<argc; ++i) printf("%d %s\n", i, argv[i]); } This works as expected... > ./test arg1 #arg2 arg3 0 ./test 1 arg1 2 #arg2 3 arg3 Running under lldb gives this... > lldb ./test arg1 #arg2 arg3 (lldb) target create "./test" Current executable set to '/Users/richard/Work/test' (arm64). (lldb) settings set -- target.run-args "arg1" "#arg2" "arg3" (lldb) run Process 6138 launched: '/Users/richard/Work/test' (arm64) 0 /Users/richard/Work/test 1 arg1 Process 6138 exited with status = 0 (0x00000000) I get the same if I quote the arguments, or if I add them to the run line. Stepping into main() we see the argv and args values are as though we only had the first argument. If I quote the second argument and add an initial space " #arg1" then it works. I first saw this on an M1 running Sequoia 13.1. It am now on OS 13.3. lldb --version lldb-1600.0.39.109 Apple Swift version 6.0.3 (swiftlang-6.0.3.1.10 clang-1600.0.30.1)

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.

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?

Chrome has started crashing almost immediately after startup. I've reported the issue to the Chrome team here: https://issues.chromium.org/issues/385433270 I'm hoping to debug the issue a bit more myself. This page from the Chrome team https://chromium.googlesource.com/chromium/src/+/master/docs/mac/debugging.md#chrome-builds suggests using the follow to strip off the protections: codesign --force --sign - path/to/Google\ Chrome.app However, applying that seems to have no effect: % codesign --force --sign - /Applications/Google\ Chrome\ copy.app /Applications/Google Chrome copy.app: replacing existing signature /Applications/Google Chrome copy.app: resource fork, Finder information, or similar detritus not allowed % lldb /Applications/Google\ Chrome\ copy.app (lldb) target create "/Applications/Google Chrome copy.app" Current executable set to '/Applications/Google Chrome copy.app' (arm64). (lldb) run error: process exited with status -1 (attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.)) I have tried other variations like the following based on Stack Overflow, this forum, etc., but with the same result. (I'm still a little vague on the meaning for some flags, sorry.) Though codesign says that it's "replacing existing signature", as far as I can tell, nothing is changing: % cat <<EOF > debuggee-entitlement.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.security.get-task-allow</key> <true/> </dict> </plist> EOF % codesign --verbose=4 -fs - --options library-validation --entitlements debuggee-entitlement.xml /Applications/Google\ Chrome\ copy.app /Applications/Google Chrome copy.app: replacing existing signature /Applications/Google Chrome copy.app: resource fork, Finder information, or similar detritus not allowed file with invalid attached data: Disallowed xattr com.apple.FinderInfo found on /Applications/Google Chrome copy.app lldb still fails the same way. Here's what I see after the above: % codesign -d -vvv /Applications/Google\ Chrome\ copy.app Executable=/Applications/Google Chrome copy.app/Contents/MacOS/Google Chrome Identifier=com.google.Chrome Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=1821 flags=0x12a00(kill,restrict,library-validation,runtime) hashes=46+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=5d7beab2b03d9892426076b24acc19815d7a3ff8 CandidateCDHashFull sha256=5d7beab2b03d9892426076b24acc19815d7a3ff8c1446966e422c3c10672626b Hash choices=sha256 CMSDigest=5d7beab2b03d9892426076b24acc19815d7a3ff8c1446966e422c3c10672626b CMSDigestType=2 CDHash=5d7beab2b03d9892426076b24acc19815d7a3ff8 Signature size=8989 Authority=Developer ID Application: Google LLC (EQHXZ8M8AV) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Dec 17, 2024 at 2:47:58 PM Notarization Ticket=stapled Info.plist entries=44 TeamIdentifier=EQHXZ8M8AV Runtime Version=15.0.0 Sealed Resources version=2 rules=13 files=63 Internal requirements count=1 size=288 From what I can tell, my codesign runs have changed nothing... I see no diff as compared with what I see running codesign -d on a fresh copy. Is it possible to strip off the protections on my local instance to allow debugging with lldb? If so, could someone share a command for accomplishing that? Although I'm asking about this because of Chrome specifically, I'm hoping to learn more about codesigning in general and to be more empowered as a user to be able to debug when an app I depend on is crashing. Thanks much! Happy Holidays!

everything works fine in Xcode15, but in Xcode16 it break down. when I add breakpoint, I start po variable , the lldb shows error: type for self cannot be reconstructed: type for typename "$s8XYRouter8RegistryOXMtD" 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. how can I fix the issues!!!. it really mattttttes, and it cause cant developing as normally. pls, save the child.

Is there a way I can use the lldb user defined commands, which I can load from a KDK, to determine how much memory my kext has consumed? Is there a way to figure out what size blocks they are? I have already run the showallclasses command and the output has assured me that I am not leaking any objects which are defined by my driver's classes. Thanks, Tim

I am building an MPI C project in Xcode. In order to do run it, I had to: Specify /path/to/mpiexec in Edit Scheme -> Run -> Info -> Executable, instead of the "default" one, say myprogram if my target is called myprogram. Specify the following arguments in Edit Scheme -> Run -> Arguments -> Arguments Passed On Launch: -np 4, ${BUILT_PRODUCTS_DIR}/${EXECUTABLE_NAME} This is clearly analogous to a mpiexec -np 4 a.out command launched on terminal. The problem is, when I want to debug my application, the execution doesn't "stop" on the breakpoints. I instantly thought that it is because of the check box Debug Executable in Edit Scheme -> Run -> Info -> Executable. Indeed (as I have just said), the Executable specified in there is mpiexec and not myprogram. Thus, is there an option or some command I could set in Xcode to attach the lldb to myprogram?

Hello! We're working on a large app with over 400 modules in both Swift and Objective-C, totaling more than 3 million lines of code. Since the release of Xcode 15 and 16 this summer, we’ve been experiencing issues with LLDB that have made debugging practically impossible. Here are some of the problems we’re facing: The first breakpoint takes a very long time to hit. When using 'po self', we encounter the following error: error: type for self cannot be reconstructed: type for typename "$s5MyModule10PlayerViewCD" 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. We get numerous log messages like this: Debugging will be degraded due to missing types. Rebuilding the project will regenerate the needed module files.warning: (arm64) /Users/egormerkushev/Library/Developer/Xcode/DerivedData/App-enhtbwiyebmjsffoqkqhhpshsfia/Build/Products/Debug-iphoneos/MyModule.framework/MyModule(UploadConfiguration.o) 0x000000000000079d: unable to locate module needed for external types: /Users/builder/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/169D1N0MIKBUI/Security-3BRN4UPIIGHME.pcm error: '/Users/builder/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/169D1N0MIKBUI/Security-3BRN4UPIIGHME.pcm' does not exist In the Derived Data folder, we find files with hash-like names, such as: Security-3JM2E93YFDLZNYHWPPIMWNENB.d Security-3JM2E93YFDLZNYHWPPIMWNENB.dia Security-3JM2E93YFDLZNYHWPPIMWNENB.pcm Security-3JM2E93YFDLZNYHWPPIMWNENB.scan Security-3NAAT3MGN7XY96KVJW529HR41.d Security-3NAAT3MGN7XY96KVJW529HR41.dia Security-3NAAT3MGN7XY96KVJW529HR41.pcm Security-3NAAT3MGN7XY96KVJW529HR41.scan Security-3RJH8STJC01N1KKN7JCY1WK7F.d Security-3RJH8STJC01N1KKN7JCY1WK7F.dia Security-3RJH8STJC01N1KKN7JCY1WK7F.pcm Security-3RJH8STJC01N1KKN7JCY1WK7F.scan Security-3TILE9XTY0B8UV9VYL7Y0MJN.d Security-3TILE9XTY0B8UV9VYL7Y0MJN.dia Security-3TILE9XTY0B8UV9VYL7Y0MJN.pcm Security-3TILE9XTY0B8UV9VYL7Y0MJN.scan Security-3ZE8O6ZPHE4L52UZGL0PCBA59.d Security-3ZE8O6ZPHE4L52UZGL0PCBA59.dia ... When enabling LLDB logs with: log enable -f /tmp/lldb.log lldb all we end up with a 1.5GB log file containing hundreds of thousands of error messages. Finally, the LLDB console output in Xcode ends with errors like: error: Assertion failed: (byte_size > 0 && byte_size <= 8 && "GetMaxU64 invalid byte_size!"), function GetMaxU64, file DataExtractor.cpp, line 527 Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 LLDB 0x0000000116ccfe1c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56 1 LLDB 0x000000011682fdcc lldb_private::lldb_assert(bool, char const*, char const*, char const*, unsigned int) + 148 2 LLDB 0x000000011682944c lldb_private::DataExtractor::GetMaxU64(unsigned long long*, unsigned long) const + 72 3 LLDB 0x00000001167335a8 lldb_private::CompilerType::GetValueAsScalar(lldb_private::DataExtractor const&, unsigned long long, unsigned long, lldb_private::Scalar&, lldb_private::ExecutionContextScope*) const + 304 4 LLDB 0x000000011666f0f4 lldb_private::Value::ResolveValue(lldb_private::ExecutionContext*, lldb_private::Module*) + 388 5 LLDB 0x0000000116671e94 lldb_private::ValueObject::ResolveValue(lldb_private::Scalar&) + 104 6 LLDB 0x0000000116674d6c lldb_private::ValueObject::GetValueAsSigned(long long, bool*) + 140 7 LLDB 0x000000011650510c lldb::SBValue::GetValueAsSigned(long long) + 160 8 lldb-rpc-server 0x00000001025ebe70 rpc_server::_ZN4lldb7SBValue16GetValueAsSignedEx::HandleRPCCall(rpc_common::Connection&, rpc_common::RPCStream&, rpc_common::RPCStream&) + 92 ... 13 libsystem_pthread.dylib 0x00000001917fb2e4 _pthread_start + 136 14 libsystem_pthread.dylib 0x00000001917f60fc thread_start + 8 Please file a bug report against lldb reporting this failure log, and as many details as possibleerror: Assertion failed: (byte_size > 0 && byte_size <= 8 && "GetMaxU64 invalid byte_size!"), function GetMaxU64, file DataExtractor.cpp, line 527 Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 LLDB 0x0000000116ccfe1c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56 1 LLDB 0x000000011682fdcc lldb_private::lldb_assert(bool, char const*, char const*, char const*, unsigned int) + 148 2 LLDB 0x000000011682944c lldb_private::DataExtractor::GetMaxU64(unsigned long long*, unsigned long) const + 72 3 LLDB 0x00000001167335a8 lldb_private::CompilerType::GetValueAsScalar(lldb_private::DataExtractor const&, unsigned long long, unsigned long, lldb_private::Scalar&, lldb_private::ExecutionContextScope*) const + 304 4 LLDB 0x000000011666f0f4 lldb_private::Value::ResolveValue(lldb_private::ExecutionContext*, lldb_private::Module*) + 388 5 LLDB 0x0000000116671e94 lldb_private::ValueObject::ResolveValue(lldb_private::Scalar&) + 104 6 LLDB 0x0000000116674c44 lldb_private::ValueObject::GetValueAsUnsigned(unsigned long long, bool*) + 140 7 LLDB 0x0000000116505224 lldb::SBValue::GetValueAsUnsigned(unsigned long long) + 160 8 lldb-rpc-server 0x00000001025ebf18 rpc_server::_ZN4lldb7SBValue18GetValueAsUnsignedEy::HandleRPCCall(rpc_common::Connection&, rpc_common::RPCStream&, rpc_common::RPCStream&) + 92 9 lldb-rpc-server 0x00000001025f62b8 rpc_common::Connection::PrivateHandleRPCPacket(rpc_common::RPCPacket&, rpc_common::RPCPacket&, bool&) + 628 10 lldb-rpc-server 0x00000001025f9e8c Packets::ProcessPackets() + 564 11 lldb-rpc-server 0x00000001025f9bf4 Packets::ReadThread() + 276 12 lldb-rpc-server 0x00000001025f9ad4 Packets::RunReadThread(void*) + 12 13 libsystem_pthread.dylib 0x00000001917fb2e4 _pthread_start + 136 14 libsystem_pthread.dylib 0x00000001917f60fc thread_start + 8 Please file a bug report against lldb reporting this failure log, and as many details as possiblePrinting description of self: error: type for self cannot be reconstructed: type for typename "$s5MyModule10PlayerViewCD" 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. In short, our debugger is completely unusable at this point, which is severely impacting our team's ability to develop effectively. Do you have any suggestions on how we can resolve these issues? We would really appreciate your help. Thank you!

The kernel sends SIGKILL to application if it handles ES_EVENT_TYPE_AUTH_OPEN and lldb is attached to this process. App: int main(int /*argc*/, char** /*argv*/) { es_client_t *pEpClient = nullptr; es_new_client_result_t result = es_new_client(&pEpClient, ^(es_client_t *pClient, const es_message_t *pMessage) { switch (pMessage->event_type) { case ES_EVENT_TYPE_AUTH_OPEN: { uint32_t authorizedFlags = pMessage->event.open.fflag; if ((authorizedFlags & FREAD) || (authorizedFlags & FWRITE)) { std::filesystem::path filePath = std::string(pMessage->event.open.file->path.data, pMessage->event.open.file->path.length); std::string fileName = filePath.filename(); if (fileName == "test.txt") { std::cout << "blocked fileName: " << filePath.filename() << std::endl; authorizedFlags &= ~FWRITE; authorizedFlags &= ~FREAD; } } if (es_respond_flags_result(pClient, pMessage, authorizedFlags, false) != ES_RESPOND_RESULT_SUCCESS) { std::cout << "es_respond_flags_result() failed with error " << std::endl; } } break; default: break; } }); if (result != ES_NEW_CLIENT_RESULT_SUCCESS) { std::cout << "es_new_client() failed." << std::endl; return 1; } es_event_type_t eventsList[] = { ES_EVENT_TYPE_AUTH_OPEN }; if (es_subscribe(pEpClient, eventsList, 1) == ES_RETURN_ERROR) { std::cout << "es_subscribe() failed." << std::endl; } // wait int i = 0; std::cin >> i; if (es_delete_client(pEpClient) == ES_RETURN_ERROR) { std::cout << "es_delete_client() failed." << std::endl; } return 0; } (lldb) process attach --pid 61127 .... (lldb) c Process 61127 resuming Process 61127 exited with status = 9 (0x00000009) Terminated due to signal 9 System log: Allowing set_exception_ports from [debugserver] on [ep_sample] for entitled process/debugger Client did not respond in appropriate amount of time (client pid: 61127), sent SIGKILL

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.

When I run my app on iOS 18, the following gets logged to the XCode console. error: Error reading commands from file lldbinit - file not found. I've never heard of that file before. What is it, why is it needed, why does the app (unbeknown to me) try to read from it, and why is it missing?

I've downloaded xcode beta and from then I'm not able to see any messages in the debugger console. I only see the: "Message from debugger: killed" after stopping it. I tried downgrading it but since I'm using Sequoia Beta, "normal" xcode won't be compatible with this MacOs version. This is what I have: xcode Version 16.1 beta (16B5001e) Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4) Target: x86_64-apple-darwin24.0.0 lldb-1500.0.404.7 Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4) xcode-select version 2409. package-id: com.apple.pkg.CLTools_Executables version: 15.3.0.0.1.1708646388 volume: / location: / install-time: 1725364937 It can be a mess as I tried so many ways to make this work. Thanks in advance. Regards.

i'm trying to get firefox running in 10.7 but the kernel is crashing. i have it working/running/looking great on 10.8 and higher. something is happening in 10.7 that is causing the panic. i need the right kit. someone asked a similar question for 10.11: https://forums.developer.apple.com/forums/thread/108732 but feedback assistant doesn't seem like the right answer. i need this kit to move forward. right now using either the 10.7.0 or 10.7.4 kernel debug kit causes a panic on reboot; something to do with AVX and the fpu. i am hoping APPUL had enough foresight to see this would be an issue (even one year later) for people on newer architectures debugging for older, supported (until 2014) targets: this use-case definitely falls within the parameters.

I am on M1 (Xcode Version 15.4 (15F31d), MacOS 14.5 (23F79), Simulator IOS 17.4) and as far as I remember printing common usage register was possible. I am not sure why it stopped to work rid, rsi and etc (arg1 arg2 seems like still working).

Hello, I have a test bundle in my application and one of the strong request of our project is to run ui tests from command line having just application build. How to run unit tests on .app file that has a test target? What we tried xcrun devicectl device install app --device <device-identifier> <UITestBundle-Runner.app> xcrun devicectl device process launch --device <device-identifier> --start-stopped <com.apptestbundle-Runner.xcrun> It launches and is waiting pid to be attached. In lldb: device select <device-identifier> device process list Seeing process 'UITestBundle-Runner' pid. device process --pid 'pid id' It attaches and I can see 'debugserver' in the pid list, but it does not start testing and I need tests to start and run. Thanks!

Hi 👋 I need assistance in attaching the to the pid in terminal. In lldb mode I am connecting to the pid using device process attach --pid <pid-id> which gives me an error Process 505 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00000001d505c808 libsystem_kernel.dylib`mach_msg2_trap + 8 libsystem_kernel.dylib`mach_msg2_trap: -> 0x1d505c808 <+8>: ret Thanks

If one would like to perform network debugging that involves toggling wireless on and off while still remaining connected to the debugger, how can one disable wireless connections of their devices to Xcode?