Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-13162] [LLDB] LLDB disconnects from process: 'Cannot load 'CurrentModule'' when debugging external project in workspace #4462

Open
swift-ci opened this issue Jul 7, 2020 · 10 comments
Labels
bug Something isn't working LLDB for Swift

Comments

@swift-ci
Copy link

swift-ci commented Jul 7, 2020

Previous ID SR-13162
Radar None
Original Reporter minuscorp (JIRA User)
Type Bug

Attachment: Download

Environment

Apple Swift version 5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53)
Target: x86_64-apple-darwin19.5.0

Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin19.5.0
Thread model: posix
InstalledDir: /Applications/Xcode-11.5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Additional Detail from JIRA
Votes 0
Component/s LLDB for Swift
Labels Bug
Assignee None
Priority Medium

md5: fe33e274987d54790327a122e91ed609

Issue Description:

Trying to debug a xcworkspace's code that is included in a workspace (which is the main target application) resolves in the debugger getting disconnected from the process after briefly showing an error message. The trigger is just making a po call. It does not crash with v instead, which is weird to me. Sometimes the disconnection produces a lldb-rpc-server crash (attached to the issue) and also I attach the lldb log session.

warning: Swift error in fallback scratch context: error: failed to load module 'CurrentModule'


note: This error message is displayed only once. If the error displayed above is due to conflicting search paths to Clang modules in different images of the debugged executable, this can slow down debugging of Swift code significantly, since a fresh Swift context has to be created every time a conflict is encountered.

Message from debugger: The LLDB RPC server has crashed. 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.
@swift-ci
Copy link
Author

Comment by Jorge Revuelta Herrero (JIRA)

Can someone @slavapestov take a brief look at this?
Sorry for pinging

@swift-ci
Copy link
Author

swift-ci commented Aug 3, 2020

Comment by Jorge Revuelta Herrero (JIRA)

Happens in Xcode 11.6 too and in Xcode 12.0 beta 3. Wasn't it a change in the directories in the DWARF files?

@swift-ci
Copy link
Author

Comment by Jorge Revuelta Herrero (JIRA)

Still not able to debug projects imported as submodules when trying to use lldb commands on breakpoints. Sometimes the lldb process crashes just when the debugger stops, other times when the we evaluate a variable with po. Using gdb commands like v seems to work.
AST logs attached have relevant information about how the crash is produced.
Can this get some attention?

@kastiglione
Copy link

Using v and vo are good workarounds in the meantime.

Question 1: When you use po, does it fail for every variable/expression, or only specific types. I'm wondering if the type of the variable is from the nested workspace.

Question 2: How is the build setup? Does the outer workspace build the nested workspace from source every time? Or are there precompiled binaries involved?

@swift-ci
Copy link
Author

Comment by Jorge Revuelta Herrero (JIRA)

Thank you for giving this attention:
Question 1: it usually fails always, no matter if the code is from the parent project or the child one; but there are more chances to fail when resolving child's variables even though the message tells that it fails to load the parent module.
Question 2: the framework is not added as a binary neither precompiled, it gets compiled with its source code (like if it was cocoapods). And yes, the both the child and the parent module depend on precompiled source from third party providers (I.e. appcenter).

@kastiglione
Copy link

Thanks for the answers. I'd like to try to rule out the project structure, can you provide a sample project that mirrors the structure? Doesn't have to have the code, just the structure. I will create some dummy code and observe its build and lldb's loading.

It appears some of the precompiled binaries are Swift and use .swiftmodule files. Are those they built with the same Swift compiler (ie same Xcode version) that the main project is built with?

The logs show a number of issues to look into. The issues I've noted are:

  • Only two swiftmodules are loaded: Starscream and Reachability, but both from Carthage – I would expect to see one or more from your project as well, assuming your project's modules/binaries are Swift

  • There are 3 Bolts.framework (which may be an issue if they're not identical binaries)

  • The Bolts.framework depended on by FBSDKCoreKit fails to load

  • Reachability.swift appears to have been built by another user ("poufah") which is likely another computer – this could mean it was compiled with a different version of the compiler (different Xcode version), but also means that its swiftmodule can contain file system paths that exist only on the original computer

  • Further, Reachability.swift does reference a separate Xcode (/Applications/Xcode.app while yours is /Applications/Xcode-11.5.app), which may not exist on your machine (like the comment about embedded paths) and doesn't rule out the possibility of a different version of Xcode

  • There are two different module cache paths referenced, ModuleCache.noindex/2Y879RPI0UU0V and ModuleCache.noindex/3ADZAQ465WLLK – this could be caused by different compilers, or by different compiler flags

Let me know if you have any comments on these issues.

@swift-ci
Copy link
Author

Comment by Jorge Revuelta Herrero (JIRA)

I'll drop an example app ASAP but in the meanwhile:

> Reachability.swift appears to have been built by another user ("poufah") which is likely another computer – this could mean it was compiled with a different version of the compiler (different Xcode version), but also means that its swiftmodule can contain file system paths that exist only on the original computer

We use Rome as a Carthage cache so the dSYM's directories point to the person's computer who compiled and uploaded them but afaik, local dSYM's are used over those (derived data ones).

> There are 3 Bolts.framework (which may be an issue if they're not identical binaries)

When you see the project structure you'll see that we don't add Bolts in any place, but still is loaded, maybe I'm wrong on this one.

> Further, Reachability.swift does reference a separate Xcode (/Applications/Xcode.app while yours is /Applications/Xcode-11.5.app), which may not exist on your machine (like the comment about embedded paths) and doesn't rule out the possibility of a different version of Xcode.

This is because of Rome again, I use xcode-install for managing different Xcode versions buy they don't so the version is still the same (because we filter the binaries by Swift version) so even if it was compiled with 11.5 it could be used in 11.6 because the underlying Swift version is the same (is this a correct assumption?)

> Only two swiftmodules are loaded: Starscream and Reachability, but both from Carthage – I would expect to see one or more from your project as well, assuming your project's modules/binaries are Swift

The parent protect add and embed those frameworks, the child project doesn't embed them, just adds then. They're found by framework search path and this way we can compile.

I'll try to provide an example by the end of the week it during next one. But ASAP to grant you the information you might need.

@kastiglione
Copy link

> (because we filter the binaries by Swift version) so even if it was compiled with 11.5 it could be used in 11.6 because the underlying Swift version is the same (is this a correct assumption?)

Do you use Rome's cache-prefix to ensure different compiler outputs are isolated? Rome's readme has a section for [Supporting multiple Swift Versions| https://github.com/tmspzz/Rome/tree/4c68baf1c235fea20840622bfa24c5763bcecd90#supporting-multiple-swift-versions].

Even with the cache key to ensure different compilers can't mix, building on different machines can cause problems because of absolute paths that get embedded in binaries.

@swift-ci
Copy link
Author

Comment by Jorge Revuelta Herrero (JIRA)

We use the raw Swift -v output, so it has been 5.2.4 IIRC for the latest Xcode versions as a cache key, just as you linked.
dSYM's generated in derived data are not used above downloaded ones so there would be no conflict (because you generated that dSYM locally) which might be the case in the logs, anyway the main app is Sports and the framework added to the workspace is KindredKit, but both fails in resolve variables, even with local Carthage runs.

@kastiglione
Copy link

In addition to a sample project, it might be helpful to produce an lldb types log from a build that has local Carthage builds, instead of from cache.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working LLDB for Swift
Projects
None yet
Development

No branches or pull requests

2 participants