Breakpoint issue: 'self cannot be reconstructed'

Developer Tools & Services Xcode
Egor_Merkushev OP
Created Oct ’24
Replies 10
Boosts 26
Views 1.7k
Participants 7

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:

  1. The first breakpoint takes a very long time to hit.
  2. 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.
  1. 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
  1. 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
...
  1. 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.

  1. 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!

Answered by Egor_Merkushev in 819237022

I found a solution to provide metadata for all modules:

  1. Enable dSYM for Debug (note: this increases build time, even for incremental builds).
  2. Copy the necessary symlinks for the Swift modules from Derived Data to a temporary folder, e.g., /tmp/lldbmodules.
  3. Configure lldbinit locally in Xcode: 
    customLLDBInitFile = "$(SRCROOT)/lldbinit"
    with the following option: 
    settings set target.swift-module-search-paths /tmp/lldbmodules
  4. Kill the lldb-rpc-server process to ensure a clean state.
  5. Build and run.
Replies  10
Boosts  26
Views  1.7k
Participants  7
Egor_Merkushev OP
Oct ’24

Also lldb-rpc-server "eats" a lot of RAM - 8GB and more...

12
vishnu1902 OP
Oct ’24 
error: '/Users/builder/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/169D1N0MIKBUI/Security-3BRN4UPIIGHME.pcm' does not exist

I resolved this error by clearing derived data folders and rebuilding the project

But I still get the below error

error: Couldn't realize Swift AST type of self. Hint: using `v` to directly inspect variables and fields may still work.
3
dimazava_vk OP
Oct ’24

I've faced the same issue. Since (at least) Xcode 16 release debugging performance has been drastically degraded, many unobvious errors are persisting in the error logs like this:

SwiftASTContextForExpressions(module: "ModuleName", cu: "MyFile.swift")::MyMethod() -- Missing Swift module or Clang module found for "ModuleName", "imported" via SwiftDWARFImporterDelegate. Hint: Register Swift modules with the linker using -add_ast_path.

as well as other types of errors mentioned by people above. And nothing, even swift healthcheck "hints" couldn't help with it.

6
vk_vk_vk OP
Oct ’24

This is the most annoying issue I've encountered in the last 5 years of iOS development.

8
artyom-stv-joom OP
Nov ’24

We've faced the same problem in Xcode 16. As a workaround, we've added options -add_ast_path to OTHER_LDFLAGS for every framework (our internal and third party). Option template:

-Wl,-add_ast_path,$(TARGET_BUILD_DIR)/\(framework).framework/Modules/\(framework).swiftmodule/$(NATIVE_ARCH_ACTUAL)-$(LLVM_TARGET_TRIPLE_VENDOR)-$(SHALLOW_BUNDLE_TRIPLE).swiftmodule

Solution to a similar problem was described in https://github.com/florentmorin/Xcode13LLDBBug

But this workaround didn't help us eliminate errors type for self cannot be reconstructed in UI test targets. And the origin of the problem isn't clear yet.

And yes, getting LLDB ready on the first breakpoint takes a lo-o-ot of time.

4
sndive OP
Nov ’24

I see the following ways in which Apple could fix lldb issues

1 go back to gdb 2 scrap the swift runtime and make proprietary swift runtime just like it was back in NextStep days 3 scrap swift altogether and migrate back either to objc or some other language that is not overblown with features and has a working debugger cause it's 100% obvious now that swift is 10 years in making that debugger is beyond repair. Amen.

1
K.H OP
Nov ’24

The same issue, Save the child PLS!!!!!!!!!!!!!!!!!!

1
Egor_Merkushev OP
Nov ’24

I found that adding OTHER_LDFLAGS=$(inherited) -Wl,-ld_classic to the build settings fixes errors with PCM files.

Additionally, I turned off the ENABLE_DEBUG_DYLIB option.

Also, I added the path for AST, as @artyom-stv-joom suggested. Now I can po self without errors. However, the first breakpoint still takes one or two minutes, so I cannot use these options as an effective solution because we cannot move to the old linker.

4
Egor_Merkushev OP
6d

Hi everyone! We have found that the issue is caused by static Swift frameworks. If we change the Mach-type to dynamic, most of the problems are solved. We also found a comment in the thread: https://forums.swift.org/t/unable-to-inspect-local-swift-variables-or-step-over-await-calls-in-xcode/62702/97

The comment says: "Static archives often do need some manual work in the build system since there is no channel to communicate the existence of a .swiftmodule to the linker".

So, what can we do now? Should we move to the nearby libraries?

0
Egor_Merkushev OP
4d
Accepted Answer

I found a solution to provide metadata for all modules:

  1. Enable dSYM for Debug (note: this increases build time, even for incremental builds).
  2. Copy the necessary symlinks for the Swift modules from Derived Data to a temporary folder, e.g., /tmp/lldbmodules.
  3. Configure lldbinit locally in Xcode: 
    customLLDBInitFile = "$(SRCROOT)/lldbinit"
    with the following option: 
    settings set target.swift-module-search-paths /tmp/lldbmodules
  4. Kill the lldb-rpc-server process to ensure a clean state.
  5. Build and run.
0
Breakpoint issue: 'self cannot be reconstructed'
First post date Last post date
 
 
Q