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
Comments
Comment by Jorge Revuelta Herrero (JIRA) Can someone @slavapestov take a brief look at this? |
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? |
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. |
Using Question 1: When you use 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? |
Comment by Jorge Revuelta Herrero (JIRA) Thank you for giving this attention: |
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 The logs show a number of issues to look into. The issues I've noted are:
Let me know if you have any comments on these issues. |
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. |
> (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. |
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. |
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. |
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
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.
The text was updated successfully, but these errors were encountered: