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-9528] Swift 4.2 compiler segfaulting in handleDeferredImports #51979

Open
swift-ci opened this issue Dec 16, 2018 · 6 comments
Open

[SR-9528] Swift 4.2 compiler segfaulting in handleDeferredImports #51979

swift-ci opened this issue Dec 16, 2018 · 6 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-9528
Radar None
Original Reporter claus.joergensen (JIRA User)
Type Bug
Environment

Xcode 10, Swift 4.2

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

md5: a858c61247793ea4845c6517ba44fdf9

Issue Description:

We have started seeing a strange problem, appearing somewhat out of nowhere, where the compiler segfaults in handleDeferredImports. This doesn't always happen, sometimes I need to clean & rebuild 2-3 times to trigger it again, so it's very hard to determine what's the root cause of it.

I've also not been able to reproduce it in a separate sample project, but after two days of looking for solutions I'm drawing a blank.

This is the segfault: error: "Segmentation fault: 11 with following stack:"

0  swift                    0x000000011307064a PrintStackTraceSignalHandler(void*) + 42
1  swift                    0x000000011306fdfe SignalHandler(int) + 302
2  libsystem_platform.dylib 0x00007fff76391b3d _sigtramp + 29
3  libsystem_platform.dylib 000000000000000000 _sigtramp + 2311513312
4  swift                    0x0000000110605df0 swift::ClangImporter::Implementation::handleDeferredImports() + 512
5  swift                    0x00000001106058dc swift::ClangImporter::Implementation::importHeader(swift::ModuleDecl*, llvm::StringRef, swift::SourceLoc, bool, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, bool) + 1804
6  swift                    0x0000000110606754 swift::ClangImporter::importBridgingHeader(llvm::StringRef, swift::ModuleDecl*, swift::SourceLoc, bool, bool) + 932
7  swift                    0x000000011010acfd swift::CompilerInstance::performSema() + 2029
8  swift                    0x000000010f2f859b performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 731
9  swift                    0x000000010f2f4dc5 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 7717
10 swift                    0x000000010f29aa35 main + 1349
11 libdyld.dylib            0x00007fff761a808d start + 1
12 libdyld.dylib            0x0000000000000123 start + 2313519255
There's no indication to individual files or headers.

We do use a mix of Objective-C and Swift, importing ProjectModuleName-Swift.h in a lot of files, and similar, have a very large ProjectModuleName-Bridging-Header.h file. In addition to this, for legacy reasons, there's a ProjectModuleName-Prefix.pch for default Objective-C includes (yes, I know that's awful).

Unfortunately our project is proprietary, and in general too large to be shared. But I'll be happy to test out any idea on how to try and isolate the error in a test project.
@swift-ci
Copy link
Collaborator Author

Comment by Claus Joergensen (JIRA)

One thing to mention, the issue appears to go away if I compile with SWIFT_COMPILATION_MODE = wholemodule;

@belkadan
Copy link
Contributor

Can you test to see if turning off "Precompile Swift Bridging Header" also works as a workaround?

If you've got the time, can you also try with a downloadable 5.0 toolchain from https://swift.org/download/, which might provide more information about the failure?

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 4, 2019

Comment by Claus Joergensen (JIRA)

We're not seeing the issue with the Swift 5 toolchain (so far). But we're probably going to keep the wholemodule optimisation, as the compile time increases drastically (a factor two) when changing it to incremental.

@belkadan
Copy link
Contributor

belkadan commented Apr 4, 2019

Possibly related to rdar://problem/45584070 (which at this point in time also needs more investigation).

The compile time issue is something we'd like to investigate too, but if you can't share your project (here or just with Apple at https://bugreport.apple.com) it'd probably be difficult to find out what the problem is.

@swift-ci
Copy link
Collaborator Author

Comment by Claus Joergensen (JIRA)

Hey, just reporting in. Xcode 10.2.1 appears to fixed the slowness with the incremental builds, we're seeing great improvements now.

@swift-ci
Copy link
Collaborator Author

Comment by Claus Joergensen (JIRA)

The issue longer reproduces in the Swift 5 toolchain / Xcode 11, feel free to close it.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added the crash Bug: A crash, i.e., an abnormal termination of software label Dec 12, 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 crash Bug: A crash, i.e., an abnormal termination of software
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@belkadan @swift-ci @AnthonyLatsis