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!