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

Jump to bottom

[SR-5805] Module cache not being cleared? #48375

Open
davezarzycki opened this issue Aug 30, 2017 · 4 comments
Open

[SR-5805] Module cache not being cleared? #48375

davezarzycki opened this issue Aug 30, 2017 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@davezarzycki
Copy link
Collaborator

Previous ID SR-5805
Radar None
Original Reporter @davezarzycki
Type Bug
Environment

Top-of-tree (af34e39); macOS 17A358a; Xcode 9M214v (beta 6)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, ClangImporter
Assignee None
Priority Medium

md5: 15a3b805e6bfc5cf747b39e626539cee

Issue Description:

I've had intermittent bad luck compiling and/or running top-of-tree Swift these days. Jordan thinks Swift could do a better job with module versioning: "Crashes in clang::ASTReader usually mean "clear your module cache". That does mean there's a bug, though, that we're not putting the revision numbers into the module hash."

swiftc -c -sdk /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -target x86_64-apple-macosx10.9 -F /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/../../../Developer/Library/Frameworks -O -no-link-objc-runtime -force-single-frontend-invocation -parse-as-library -module-name DriverUtils -emit-module -emit-module-path /Volumes/data/wt/master/t/swift-macosx-x86_64/benchmark/O-x86_64-apple-macosx10.9/DriverUtils.swiftmodule -o /Volumes/data/wt/master/t/swift-macosx-x86_64/benchmark/O-x86_64-apple-macosx10.9/DriverUtils.o /Volumes/data/wt/master/swift/benchmark/utils/DriverUtils.swift /Volumes/data/wt/master/swift/benchmark/utils/ArgParse.swift
Assertion failed: (idx < size()), function operator[], file /Volumes/data/wt/master/llvm/include/llvm/ADT/SmallVector.h, line 153.
0  swift                    0x00000001102a0a38 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  swift                    0x000000011029f986 llvm::sys::RunSignalHandlers() + 86
2  swift                    0x00000001102a0ffe SignalHandler(int) + 366
3  libsystem_platform.dylib 0x00007fff59b53f5a _sigtramp + 26
4  libsystem_platform.dylib 0x00000001140f9588 _sigtramp + 3126482504
5  libsystem_c.dylib        0x00007fff5997f32a abort + 127
6  libsystem_c.dylib        0x00007fff59947380 basename_r + 0
7  swift                    0x000000010f7adb4a clang::ASTReader::ReadString(llvm::SmallVector<unsigned long long, 64u> const&, unsigned int&) + 682
8  swift                    0x000000010f79fc0e clang::ASTReader::ParseLanguageOptions(llvm::SmallVector<unsigned long long, 64u> const&, bool, clang::ASTReaderListener&, bool) + 12110
9  swift                    0x000000010f79cbda clang::ASTReader::ReadOptionsBlock(llvm::BitstreamCursor&, unsigned int, bool, clang::ASTReaderListener&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 250
10 swift                    0x000000010f7a1628 clang::ASTReader::ReadControlBlock(clang::serialization::ModuleFile&, llvm::SmallVectorImpl<clang::ASTReader::ImportedModule>&, clang::serialization::ModuleFile const*, unsigned int) + 1048
11 swift                    0x000000010f7a371d clang::ASTReader::ReadASTCore(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, clang::serialization::ModuleFile*, llvm::SmallVectorImpl<clang::ASTReader::ImportedModule>&, long long, long, clang::ASTFileSignature, unsigned int) + 2253
12 swift                    0x000000010f7af1a8 clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, llvm::SmallVectorImpl<clang::ASTReader::ImportedSubmodule>*) + 296
13 swift                    0x000000010f51633e clang::CompilerInstance::loadModule(clang::SourceLocation, llvm::ArrayRef<std::__1::pair<clang::IdentifierInfo*, clang::SourceLocation> >, clang::Module::NameVisibilityKind, bool) + 1886
14 swift                    0x000000010e30d9a0 swift::ClangImporter::loadModule(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >)::$_4::operator()(llvm::ArrayRef<std::__1::pair<clang::IdentifierInfo*, clang::SourceLocation> >, bool) const + 640
15 swift                    0x000000010e30d58e swift::ClangImporter::loadModule(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 462
16 swift                    0x000000010e3df8a3 swift::ASTContext::getModule(llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 115
17 swift                    0x000000010e25b13a swift::ModuleFile::getModule(llvm::ArrayRef<swift::Identifier>) + 330
18 swift                    0x000000010e28900b swift::ModuleFile::associateWithFileContext(swift::FileUnit*, swift::SourceLoc) + 1579
19 swift                    0x000000010e2e0785 swift::SerializedModuleLoader::loadAST(swift::ModuleDecl&, llvm::Optional<swift::SourceLoc>, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, bool) + 629
20 swift                    0x000000010e2e2e32 swift::SerializedModuleLoader::loadModule(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 466
21 swift                    0x000000010e3df8a3 swift::ASTContext::getModule(llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 115
22 swift                    0x000000010e3df95f swift::ASTContext::getStdlibModule(bool) + 63
23 swift                    0x000000010deef7e6 swift::CompilerInstance::performSema() + 454
24 swift                    0x000000010d47014c performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 1740
25 swift                    0x000000010d46eb70 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 3408
26 swift                    0x000000010d42fc30 main + 3184
27 libdyld.dylib            0x00007fff598d3145 start + 1
@davezarzycki
Copy link
Collaborator Author

I've also seen the builtin (non-LLDB) REPL randomly crash like this too.

@belkadan
Copy link
Contributor

Yeah, the integrated REPL is basically just the compiler.

@davezarzycki
Copy link
Collaborator Author

Lately (like the last week or two or so), it seems like the module cache system has become quite brittle. Even after deleting the per user cache, my clean build failed, and I needed to remove the freshly built cache within the build directory itself and start the build over to finish the build successfully.

Am I bringing this upon myself? I have multiple Swift work trees setup so that I can work on something else while a branch builds. Does the system wide cache assume one work tree?

@belkadan
Copy link
Contributor

There's a good chance this is just the effects of rebranching LLVM and Clang, meaning we've slurped in a ton of changes. We're probably this broken all the time, but the AST serialization stuff doesn't change very often during a particular release.

We're not supposed to be assuming one work tree because we're supposed to encode revision numbers in the cache.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@belkadan @davezarzycki