[SR-12050] lldb error: could not build C module 'CNIOBoringSSLShims' (Linux 5.1.3) #4623
Comments
|
CC @dcci/@adrian-prantl |
|
@swift-ci create |
|
CC @tomerd |
|
> error: /Users/johannes/devel/swift-nio-ssl/Sources/CNIOBoringSSLShims/include/CNIOBoringSSLShims.h:22:10: error: 'CNIOBoringSSL.h' file not found Looks like you are missing an include path for swift-nio-ssl/Sources/CNIOBoringSSL/include. |
|
@adrian-prantl how do you mean I'm missing the include path? The compilation works fine and then I'm trying to debug the binary which then raises that error. Do you mean the binary lacks the right information on where to find that header? |
|
I can't say. I'm building a toolchain and the project at the moment to capture a types log to tell us why. |
|
But yes, the Clang compiler instance that compiles `CNIOBoringSSLShims.h` on Swift's behalf in LLDB is missing the include path to that header. The path should get deserialized from the NIOTLS module, but perhaps you're building without serialized compiler flags or something else... |
|
@adrian-prantl Cool, let me know if I can give you more info. See the above repro, I literally just compile with that's it. So I'd expect SwiftPM to pass all required things. I use Docker (on macOS), so after installing Docker for Mac, the following commands are enough (assuming you've got the NIO checkout): |
|
I'm having trouble building a working toolchain at the moment (need to figure out why I can't get swiftpm to build ...). Can you capture a types log from LLDB (put "log enable lldb types -f /tmp/types.log" into ~/.lldbinit-Xcode or ~/.lldbinit)? I might be able to see what is going on there. |
|
@adrian-prantl attached |
|
docker command line to get the information straight from macOS: Attaching |
|
This seems more of a swiftpm quirks than an LLDB bug: To reiterate the problem is that the CNIOBoringSSL module can't be found at debug time.
If we look at the serialized import paths from the log: {{ SwiftASTContextForExpressions::LogConfiguration(SwiftASTContext*)0x3b34cf0:}} It looks as though the main program was built with explicit Clang modules, which I find surprising. In any case I assume that at debug time, this path Johannes, as a workaround, all you need to do is pass a |
|
@adrian-prantl the path |
|
|
Comment by Mark Troyer (JIRA) For possibly a little more info, I'm running into the same issue with CNIBoringSSL trying to test async-http-client in the REPL. Everything looks like it builds find and the REPL starts, but when you try to import AsyncHTTPClient you get the same errors with CNIBoringSSL: Note that the Perhaps more interesting is editing the What I find interesting here is that now there are errors about redefinitions and multiple inclusions, leading me to believe that it is in fact finding and loading the |
|
Putting absolute paths into module maps only works by accident and is not something that should be done. I think the swiftpm folks are aware of this and are working on a fix. |
|
Comment by Mark Troyer (JIRA) The module map is unmodified, the change I made was in the CNIOBoringSSLShims.h file, and was done as an experiment to see if further errors would be generated and perhaps shed more light on the problem. |
|
also affects gRPC Swift with the REPL: grpc/grpc-swift#820 |
|
Comment by Ryan (JIRA) Similar issue debugging system module includes on linux - LLDB cannot find headers and so cannot load AST modules, crippling debugging: warning: (x86_64) /home/ryan/Projects/Develop/Tsunami/.build/debug/Tsunami unable to load swift module "Logging" (failed to get module "Earthquake" from AST context:
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "include/cpipewire.h"
^
error: /home/ryan/Projects/Develop/Tsunami/Sources/CPipewire/include/cpipewire.h:1:10: error: 'spa/param/audio/format-utils.h' file not found
#include <spa/param/audio/format-utils.h>
^
error: could not build C module 'CPipewire'
)
warning: (x86_64) /home/ryan/Projects/Develop/Tsunami/.build/debug/Tsunami unable to load swift module "Propellor" (failed to get module "Earthquake" from AST context:
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "include/cpipewire.h"
^
error: /home/ryan/Projects/Develop/Tsunami/Sources/CPipewire/include/cpipewire.h:1:10: error: 'spa/param/audio/format-utils.h' file not found
#include <spa/param/audio/format-utils.h>
^
error: could not build C module 'CPipewire'
)
warning: (x86_64) /home/ryan/Projects/Develop/Tsunami/.build/debug/Tsunami unable to load swift module "Signals" (failed to get module "Earthquake" from AST context:
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "include/cpipewire.h"
^
error: /home/ryan/Projects/Develop/Tsunami/Sources/CPipewire/include/cpipewire.h:1:10: error: 'spa/param/audio/format-utils.h' file not found
#include <spa/param/audio/format-utils.h>
^
error: could not build C module 'CPipewire'
)
warning: (x86_64) /home/ryan/Projects/Develop/Tsunami/.build/debug/Tsunami unable to load swift module "Tsunami" (failed to get module "Earthquake" from AST context:
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "include/cpipewire.h"
^
error: /home/ryan/Projects/Develop/Tsunami/Sources/CPipewire/include/cpipewire.h:1:10: error: 'spa/param/audio/format-utils.h' file not found
#include <spa/param/audio/format-utils.h>
^
error: could not build C module 'CPipewire' |
|
Comment by Ryan (JIRA) Turns out a workaround is to manually specify the system header locations in ~/.lldbinit as follows: settings set -- target.swift-extra-clang-flags -I/usr/local/include/pipewire-0.3 -I/usr/local/include/spa-0.2 |
|
> Similar issue debugging system module includes on linux - LLDB cannot find headers and so cannot load AST modules, crippling debugging: This bugreport is about a swiftpm bug. Are you sure yours is too? I appreciate the report, but please try to not tack on new issues on an existing bugreport. So far, there is nothing in the log output you posted that would indicate to me that this is the same issue at all. It is very easy to mark a new bugreport as a duplicate after we figure out that it has indeed the same root cause. By adding on to existing bugreports you are risking that we won't realize something else needs fixed until after the first bug is fixed. |
|
Comment by Ryan (JIRA) In both my and the OP's report, the symptoms (LLDB not importing a module when setting a breakpoint due to being unable to find external headers and therefore not displaying frame variables) and the workaround (passing -I<header path> manually in .lldbinit) are the same. Another user has noted the same issue in grpc-swift. Do you have any evidence the bugs are different? If not I would prefer not to add any further noise to the tracker by adding an extra bug. |
|
As long as you have verified that your project also has a swiftpm-generated module map file that uses absolute paths to temporary headers then that's fine — I just didn't see any indication that this is the case in your comment. Drawing conclusions from just symptoms alone is dangerous because there are so many moving parts involved. But really, don't hesitate to file new bugs: it's very cheap to mark them as duplicate and that also allows us to look at the number of times a bug has been reported as a rough indicator of what bugfix would affect the most users and when deciding on what to tackle next. |
|
Comment by Ryan (JIRA) I have reviewed the lldb build log as suggested above, and you are correct, there is no mention of a temporary module. lldb SwiftASTContext("Tsunami")::SetTriple("x86_64-unknown-linux-gnu") setting to "x86_64-unknown-linux-gnu"
lldb SwiftASTContext("Tsunami")::SetTriple("x86_64-unknown-linux-gnu") setting to "x86_64-unknown-linux-gnu"
lldb SwiftASTContext("Tsunami")::DeserializeAllCompilerFlags() -- Found 1 AST file data entries.
lldb SwiftASTContext("Tsunami")::DeserializeAllCompilerFlags() -- SDK path from module "ArgumentParser" was "".
lldb SwiftASTContext("Tsunami")::DeserializeAllCompilerFlags() -- SDK path from module "Earthquake" was "".
lldb SwiftASTContext("Tsunami")::DeserializeAllCompilerFlags() -- SDK path from module "HeliumLogger" was "".
lldb SwiftASTContext("Tsunami")::DeserializeAllCompilerFlags() -- SDK path from module "LoggerAPI" was "".
lldb SwiftASTContext("Tsunami")::DeserializeAllCompilerFlags() -- SDK path from module "Logging" was "".
lldb SwiftASTContext("Tsunami")::DeserializeAllCompilerFlags() -- SDK path from module "Propellor" was "".
lldb SwiftASTContext("Tsunami")::DeserializeAllCompilerFlags() -- SDK path from module "Signals" was "".
lldb SwiftASTContext("Tsunami")::DeserializeAllCompilerFlags() -- SDK path from module "Tsunami" was "".
lldb SwiftASTContext("Tsunami")::DeserializeAllCompilerFlags() -- Picking SDK path "".
lldb SwiftASTContext("Tsunami")::CreateInstance() -- Found serialized triple x86_64-unknown-linux-gnu.
lldb SwiftASTContext("Tsunami")::SetTriple("x86_64-unknown-linux-gnu") setting to "x86_64-unknown-linux-gnu"
lldb SwiftASTContext("Tsunami")::CreateInstance() -- No serialized SDK path.
lldb SwiftASTContext("Tsunami")::CreateInstance() -- Host SDK path is .
lldb SwiftASTContext("Tsunami")::GetASTContext() -- Using Clang module cache path: /home/ryan/.cache/clang/ModuleCache
lldb SwiftASTContext("Tsunami")::GetASTContext() -- Using prebuilt Swift module cache path: /home/ryan/Projects/Develop/swift-toolchain/usr/lib/swift/linux/prebuilt-modules
lldb SwiftASTContext("Tsunami")::GetModule("ArgumentParser")
lldb SwiftASTContext("Tsunami")::GetModule("ArgumentParser") -- found ArgumentParser
lldb SwiftASTContext("Tsunami")::GetModule("Earthquake")
lldb SwiftASTContext("Tsunami")::GetModule("Earthquake") -- <module-includes>:1:10: note: in file included from <module-includes>:1:
#include "include/cpipewire.h"
^error: /home/ryan/Projects/Develop/Tsunami/Sources/CPipewire/include/cpipewire.h:1:10: error: 'spa/param/audio/format-utils.h' file not found
#include <spa/param/audio/format-utils.h>
^error: could not build C module 'CPipewire' Thanks for the explanation. Happy to create a new bug in that case. |
|
This turned out to be because SwiftPM wasn't prefixing the `-I foo/bar/include` with `-Xcc` arguments, so the search paths were not serialized to the AST properly. Many thanks to @adrian-prantl for his help in figuring this out! |
|
Awesome, thank you @adrian-prantl & @abertelrud |
|
I tried to validate this but then ran into https://bugs.swift.org/browse/SR-14099 (can't run lldb at all), so I couldn't verify this just yet. |
|
thank you, this is definitely fixed on |
Attachment: Download
Additional Detail from JIRA
md5: b5d007fe6ad9340cfe7f15dc14197742
Issue Description:
LLDB on Linux has improved a lot recently, however, there are still some basic, easy to repro failure modes. Here's an example repo:
and then within lldb:
you'll see many errors like
Please note, that BoringSSL is fully vendored through SwiftPM so this doesn't rely on any system-installed ssl library!
when you then
runthe target, you'll very soon hit the breakpoint and you'll seenote all the
unavailables. Trying topthe variables always leads toThe text was updated successfully, but these errors were encountered: