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-7932] Cannot load Swift type information; AST validation error: The serialized module is corrupted. / Swift expressions require OS X 10.10 / iOS 8 SDKs or later #4495

Closed
swift-ci opened this issue Jun 8, 2018 · 9 comments
Labels
bug Something isn't working LLDB for Swift

Comments

@swift-ci
Copy link

swift-ci commented Jun 8, 2018

Previous ID SR-7932
Radar rdar://problem/57110020
Original Reporter rlovelett (JIRA User)
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Environment
  • Ubuntu 18.04 bionic

  • lldb version 6.0.0 (revision 5f25df7854828f00daba8dd88c5886a4599f90c4)

  • Swift-4.2 (revision f2c0f1d9d6aa01a09093ed95d679bf3b3b6188da)

  • clang (revision 5272858825c89a190a98e96d457466c8db5df92d)

  • llvm (revision a38ff55b315aa8d181b162278dae5042a1e7e803)

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

md5: 95cb740bfc0f8091c81fb39249c85f43

is duplicated by:

  • SR-11897 LLDB can't load type information

Issue Description:

When trying to use lldb to debug I cannot seem to get variable information or really any frame information.

Executable module set to "/home/rlovelett/Source/langserver-swift/.build/x86_64-unknown-linux/debug/langserver-swift".
Architecture set to: x86_64--linux.
(lldb) breakpoint set --file library_wrapper.swift --line 84
Breakpoint 1: where = langserver-swift`SourceKitter.Loader.load(path: Swift.String) -> SourceKitter.DynamicLinkLibrary + 1240 at library_wrapper.swift:84, address = 0x0000562d5aef5f78
(lldb) c
Process 5283 resuming
Process 5283 stopped and restarted: thread 1 received signal: SIGCHLD
Process 5283 stopped and restarted: thread 1 received signal: SIGCHLD
Process 5283 stopped and restarted: thread 1 received signal: SIGCHLD
Process 5283 stopped and restarted: thread 1 received signal: SIGCHLD
Process 5283 stopped
* thread #​7, name = 'langserver-swif', stop reason = breakpoint 1.1
    frame #&#8203;0: 0x0000562d5aef5f78 langserver-swift`Loader.load(path=<unavailable>, self=<unavailable>) at library_wrapper.swift:84
   81           // try all fullPaths that contains target file,
   82           // then try loading with simple path that depends resolving to DYLD
   83           for fullPath in fullPaths + [path] {
-> 84               if let handle = dlopen(fullPath, RTLD_LAZY) {
   85                   return DynamicLinkLibrary(path: path, handle: handle)
   86               }
   87           }
Target 0: (langserver-swift) stopped.
(lldb) frame variable
path = <could not resolve type>
self = <could not resolve type>
fullPaths = <could not resolve type>
fullPath = <could not resolve type>
handle = <could not resolve type>
(lldb) po fullPath
error: expression failed to parse, unknown error
(lldb) po fullPath
error: Swift expressions require OS X 10.10 / iOS 8 SDKs or later.

I have tracked that last error, the Swift expressions require OS X 10.10 / iOS 8 SDKs or later. to line 1101 in SwiftExpressionParser.cpp.

@belkadan
Copy link

belkadan commented Jun 9, 2018

cc jingham@apple.com (JIRA User)

@swift-ci
Copy link
Author

swift-ci commented Jun 9, 2018

Comment by Ryan Lovelett (JIRA)

This is a blocker for my work porting my Swift language server to Linux. I've already hit a few other snags trying to get a working debugger on Linux. I'm ready and willing to roll up my proverbial sleeves to help solve this. It just might take a mentor (or two) to help me; like on my last LLDB adventure.

@swift-ci
Copy link
Author

Comment by Jim Ingham (JIRA)

That error message is pretty bogus. The error is because we couldn't make a ClangImporter to reconstruct the types of any bridged objects in your swift module. You can get some better debugging for this in a couple of ways. Turn on the types log by putting this in your .lldbinit:

log enable f /tmp/lldbtypes-log.txt lldb types

then generating the error and see if there are any interesting errors in that log. You can also get some diagnostics from clang & swift by setting the environment variable LLDB_SWIFT_DUMP_DIAGS before you run lldb.

Clang needs to find the same system headers that it found when building your program, so that it can reconstruct any clang modules that were being used to import types into swift. The error message is just a guess of what might have happened to cause this on macOS. The output from the types log and the environment variable should give more helpful info.

@swift-ci
Copy link
Author

Comment by Ryan Lovelett (JIRA)

Okay that definitely gives a little bit more information.

Now in lldb I consistently get messages like this <unknown>:0: error: missing required module 'SourceKit' or error in SwiftASTContext::GetModule(SourceKitter): 'error: missing required module 'SourceKit'. Though what is odd, that the /tmp/lldbtypes-log.txt file never gets created even though I've made my $HOME/.lldbinit file look like that above.

The SourceKit module is a C system module from SwiftPM. The fact that it is a C module, does not feel like a coincidence. I remember having issues with C modules back in Swift 2-3 on macOS.

Looking in .build/debug it seems the SourceKit module is not there (that is there is no SourceKit.swiftmodule). Is there a specific way to launch lldb with so as to provide SwiftPM packages or C system modules dependencies?

@swift-ci
Copy link
Author

swift-ci commented Feb 4, 2019

Comment by Tabor Kelly (JIRA)

I ran into this problem on my own and posted a full write-up here:
https://github.com/TaborKelly/AvahiClient

It would appear that the symbols are there (look for .pcm files in .build/x86_64-unknown-linux/debug/ModuleCache/)? However, I still don't know how to work around or fix this problem.

@swift-ci
Copy link
Author

Comment by Renan Jegouzo (JIRA)

Should be in high priority, can't debug on linux until it's fixed.. So all linux swift works on hang..

@weissi
Copy link
Member

weissi commented Nov 12, 2019

CC @dcci this still reproduces on 5.1.2. Here's a one-liner to compile & install everything from a Mac:

cd /tmp && if [[ ! -d AvahiClient ]]; then git clone https://github.com/TaborKelly/AvahiClient.git; fi && cd AvahiClient && docker run -it --privileged --rm -v "$PWD:$PWD" -w "$PWD" swift:5.1.2 bash -c 'apt-get update && apt-get -yy install libavahi-client-dev && swift build --build-tests && LLDB_SWIFT_DUMP_DIAGS=1 lldb ./.build/x86_64-unknown-linux/debug/AvahiClientPackageTests.xctest'

broken into multiple lines

cd /tmp
if [[ ! -d AvahiClient ]]; then git clone https://github.com/TaborKelly/AvahiClient.git; fi
cd AvahiClient
docker run -it --privileged --rm -v "$PWD:$PWD" -w "$PWD" swift:5.1.2 bash -c 'apt-get updateapt-get -yy install libavahi-client-dev && swift build --build-tests && LLDB_SWIFT_DUMP_DIAGS=1 lldb ./.build/x86_64-unknown-linux/debug/AvahiClientPackageTests.xctest'

that will install the dependencies and compile the tests and should leave you in the lldb console. In there, do

(lldb) breakpoint set -f AvahiClientTests.swift -l 12
(lldb) breakpoint set -f AvahiClientTests.swift -l 14
(lldb) run

then, depending on which breakpoint you hit, do

(lldb) po error

or

(lldb) po c

here's a full trace:

(lldb) target create "./.build/x86_64-unknown-linux/debug/AvahiClientPackageTests.xctest"
Current executable set to './.build/x86_64-unknown-linux/debug/AvahiClientPackageTests.xctest' (x86_64).
(lldb) breakpoint set -f AvahiClientTests.swift -l 12
Unable to load module.
Breakpoint 1: where = AvahiClientPackageTests.xctest`AvahiClientTests.AvahiClientTests.testNewAvahiClient() -> () + 129 at AvahiClientTests.swift:12:19, address = 0x00000000000045f1
(lldb) breakpoint set -f AvahiClientTests.swift -l 14
Breakpoint 2: where = AvahiClientPackageTests.xctest`AvahiClientTests.AvahiClientTests.testNewAvahiClient() -> () + 411 at AvahiClientTests.swift:14:21, address = 0x000000000000470b
(lldb) run
Process 414 launched: '/tmp/AvahiClient/.build/x86_64-unknown-linux/debug/AvahiClientPackageTests.xctest' (x86_64)
Test Suite 'All tests' started at 2019-11-12 09:46:15.430
Test Suite 'debug.xctest' started at 2019-11-12 09:46:15.431
Test Suite 'AvahiClientTests' started at 2019-11-12 09:46:15.432
Test Case 'AvahiClientTests.testNewAvahiClient' started at 2019-11-12 09:46:15.433
/tmp/AvahiClient/.build/x86_64-unknown-linux/debug/AvahiClientPackageTests.xctest: Cannot load Swift type information; AST validation error: The serialized module is corrupted.
Process 414 stopped
* thread #&#8203;1, name = 'AvahiClientPack', stop reason = breakpoint 2.1
    frame #&#8203;0: 0x000055555555870b AvahiClientPackageTests.xctest`AvahiClientTests.testNewAvahiClient(self=<unavailable>) at AvahiClientTests.swift:14:21
   11               let c = try AvahiClient()
   12               print(c)
   13           } catch {
-> 14               XCTFail("\(error)")
   15           }
   16       }
   17   }
Target 0: (AvahiClientPackageTests.xctest) stopped.
(lldb) po error
Unable to load module.
error: warning: failed to get module "AvahiClientTests" from AST context

error: in auto-import:
failed to get module "AvahiClientTests" from AST context
(lldb) 

Here's a full traceback: https://gist.github.com/weissi/37c3faa688b5d8ffae60c59e234fd4c2

attached also find the lldbtypes-log.txt that jingham@apple.com (JIRA User) requested.

Please also note the error message

Cannot load Swift type information; AST validation error: The serialized module is corrupted.

@weissi
Copy link
Member

weissi commented Nov 12, 2019

@swift-ci create

@adrian-prantl
Copy link
Member

apple/swift#28574

@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
This issue was closed.
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

4 participants